Name-Server-Konfiguration

Name-Server auf Unix-Maschinen (und alle davon abgeleitete oder portierte Software, etwa für OS/2) entnehmen ihre Daten der Startdatei named.boot, bzw named.conf, sowie den Zonen-Dateien. 

Andere Systeme wie Windows NT können die Informationen mit anderen Methoden festhalten - die Software des Name-Servers ist dafür zuständig, trotzdem alle Angaben korrekt an die anfragenden Maschinen zurückzuliefern. Die Angaben über Zonen und die einzelnen Ressource Records dürfen sich also nicht unterscheiden.

In der Konfiguration sind sämtliche für die Netzwerkanbindung relevanten Informationen über die Systeme innerhalb einer Domain gespeichert. Eine Zone bezeichnet in diesem Sprachgebrauch dann eine Verzweigung des DNS-Baums, die unabhängig administriert wird. Normalerweise sind das Domains unterhalb der Top-Level-Domains, diese können dann aber wiederum in kleinere Zonen (also Sub-Domains) unterteilt werden. Zonen-Dateien bestehen aus Direktiven, die dem Name-Server Anweisungen zur Interpretation der einzelnen Einträge geben, sowie aus Resource Records (den eigentlichen Informationsträgern).

Directiven

Zwei Direktiven kommen in den Zonen-Dateien vor: $INCLUDE und $ORIGIN.

$INCLUDE [Dateiname] ermöglicht, Daten zur aktuellen Zone aus einer Datei zu laden und in die aktuelle Zone mit einzubinden. Es ist allerdings nicht möglich, mittels $INCLUDE in eine andere Zone zu wechseln.

$ORIGIN [Zonenbeginn] setzt explizit den Start einer Zone. Allerdings sollte diese Direktive mit Vorsicht eingesetzt werden, da es nicht möglich ist, mittels $ORIGIN in eine völlig andere Zone zu wechseln. Vielmehr dient sie dazu, am Anfang einer Zonen-Datei die Zone explizit zu setzen. Es ist damit auch möglich, in eine untergeordnete Zone überzuwechseln, also beispielsweise von wwwa.org. in test.wwwa. org., niemals aber in eine Zone auf der gleichen Ebene (etwa von wwwa.org. nach foobar.com.).

Endet ein Name in einem Resource Record übrigens nicht mit dem abschließenden Punkt, so wird der aktuelle Wert von $ORIGIN angehängt. Dieses Verhalten ist dafür verantwortlich , dass DNS-Abfragen auch nur mit dem Anfang des FQDN durchgeführt werden. Im EBZI Bereich 52 würde ein nslookup nach lfl52s01 automatisch zu lfl52s01.lfv.bwl.de ergänzt.

Die Resource Records enthalten die eigentlichen Informationen für das DNS . Einige dieser Einträge müssen in einer Zonen-Datei enthalten sein, andere sind optional.

SOA-Records

SOA-Records kennzeichnen den Beginn einer Zone, SOA steht dabei für Start of Authority. Für jede Zone gibt es daher auch nur einen SOA-Record. Er setzt einige Parameter, die für die gesamte Zone gültig sind:

Domain	IN	SOA	origin	contact 
	( 
	serial 
	refresh 
	retry 
	expire 
	minimum 
	) 
Für die (inoffizielle) Domain lfv.bwl.de sieht der SOA-Record so aus:
@	IN	SOA 	ns.lfv.bwl.de. root.ns.lfv.bwl.de.   (
		1999112201	; serial
		86400		; refresh	=   24 h =  1,0 d
		3600		; retry		=    1 h
		2419200		; expire	=  672 h = 28,0 d
		86400)	

Die Bedeutung der Felder ist dabei wie folgt:

Im ersten Feld des SOA-Records ist die Domain aufgeführt. Meist findet sich an dieser Stelle ein @, das für die aktuelle (vorher durch eine Direktive wie $ORIGIN gesetzte) Domain steht. 
Es folgt das IN für Internet, danach der Kenner für die Art des Records (SOA, Start of Authority). 
Im Feld origin steht der volle Domain-Name des verantwortlichen Name-Servers einer Domain. 
Es folgt die Adresse der Kontaktperson, die bei Problemen mit dem Name-Server zu benachrichtigen ist (dem Hostmaster). Um daraus die eMail-Adresse zu ermitteln, muss man den ersten Punkt durch ein @ ersetzen und den letzten Punkt streichen.  Die eMail-Adresse des Hostmasters von ns.lfv.bwl.de lautet also root@ns.lfv.bwl.de
Im Feld serial steht die Seriennummer. Diese müssen bei jeder Modifikation erhöht werden, da andere Name-Server daran überprüfen, ob die zwischengespeicherten Daten noch korrekt und aktuell sind. Um Fehlkonfigurationen zu vermeiden, sollte man das Format [jahrmonattagversion] zu wählen. Version 02 vom 12.9.1999 würde also die Seriennummer 1999091202 ergeben. Bei Änderungen an einer Zonen-Datei ist grundsätzlich die Seriennummer zu erhöhen. Das Jahr sollte übrigens vierstellig angegeben werden, um Probleme infolge des Jahrtausendwechsels zu umgehen.
Refresh gibt die Zeitdauer in Sekunden an, die der Secondary wartet, bevor er beim Primary anfragt, ob sich irgendwelche Zonendaten geändert haben. Es kommt vor, daß der Primary nicht erreichbar ist. In diesem Fall versucht der Secondary es zu einem späteren Zeitpunkt noch einmal. Diese Zeitdauer läßt sich im Feld retry einstellen. Kommt es während einer Zeitdauer, die den Expire-Wert überschreitet, zu keinem Refresh, so verwirft der Secondary die von ihm gespeicherten Zonendaten. Der Wert im Minimum-Feld des SOA-Records gibt die sogenannte Time-to-Live an, die ein Record im Cache eines nicht lokalen Servers gehalten werden soll. Der Minimum-Wert ist nur von Interesse, wenn keine explizite Time-to-Live im entsprechenden Resource Record angegeben ist. Die Werte aus den Beispielen sind für schnelle Netzwerkanbindungen (zum Beispiel Ethernet, T1, E1 oder schneller) gedacht. Existiert nur eine langsame Anbindung an das Internet, so lassen sich die Intervalle vergrößern.

NS-Records

NS-Records definieren einen Name-Server für eine Domain oder Sub-Domain, und zwar im Format:

Domain	IN	NS 	Name-Server 
Dabei müssen Domain und Name-Server als Fully Qualified Domain Names angegeben werden, also beispielsweise:
WWWA.ORG.	IN	NS	Kei.CC.Uni-Augsburg.DE. 
Kei.CC.Uni-Augsburg.DE. ist also der Name-Server für die Domain WWWA. ORG. Jede Domain (und Sub-Domain) benötigt übrigens mindestens zwei Name-Server.

A-Records

A-Records übernehmen die Abbildung von Hostnamen auf IP-Adressen, und zwar im Format:

Name	IN	A	IP-Adresse 
Für Name lassen sich FQDNs einsetzen und auf diese Weise Konfigurationsfehler ausschließen. Außerdem sind relative Hostnamen zulässig. Dafür muss allerdings die Default-Domain korrekt gesetzt sein. Findet sich keine entsprechende $ORIGIN-Direktive, so entnimmt der Server den Domain-Namen der Datei /etc/ named.boot (er steht dort in der primary-Direktive):
lfl52p63.lfv.bwl.de         IN      A       10.32.52.163                  
$ORIGIN lfv.bwl.de. 
lfl52p65	 	    IN	    A	    10.33.52.165

Der erste A-Record benutzt einen FQDN, der zweite einen relativen Hostnamen.

PTR-Records

PTR-Records bilden IP-Adressen auf Hostnamen ab. Sie finden sich in den Zonendateien, die die IN-ADDR.ARPA-Zonen einer Domain implementieren. 

Die Wichtigkeit der PTR-Records ist nicht zu unterschätzen, da viele viele Dienste, die Identität des anfordernden Systems durch einen Lookup des Hostnamens überprüfen. Liefert der Systemaufruf keinen akzeptablen Wert zurück, so verweigern diese Dienste den Zugriff. Ein PTR-Record in der für 32.10.in-addr.arpa hat also die Form :

lfl52p63                IN      A       10.32.52.163                  
Ein PTR-Record enthält also die 4 Bytes der IP-Adresse in umgekehrter Reihenfolge, gefolgt von dem Anhängsel .IN-ADDR. ARPA, sowie den FQDN des Host. Auch hier ist unbedingt auf den abschließenden Punkt zu achten. Um Tipparbeit zu sparen und die Datei übersichtlicher zu gestalten, bietet es sich bei PTR-Records an, den Zonenbeginn mittels $origin explizit zu setzen. Auch ist dann das Einrichten einer Sub-Domain weniger mühsam.

MX-Records

MX-Records definieren einen Mail Exchanger für einen bestimmten Rechner oder eine Domain. Dabei handelt es sich um einen Rechner, der EMail entgegennimmt:

lfl52p63.lfv.bwl.de      IN      A       10.32.52.163 
       		         IN      MX      100     lfl51s03.lfv.bwl.de. 
      

Für jeden Rechner, der EMail entgegennehmen kann, sollte ein MX-Record angelegt werden, da ansonsten bei der Auslieferung von EMail implizit ein MX-Record mit der Präferenz 0 angelegt wird. Meines Erachtens ist es besser, den MX explizit zu setzen, als ihn durch einen nicht-lokalen Mailer implizit setzen zu lassen. Mail Exchanger mit niedriger Präferenz werden gegenüber denen mit höherer Präferenz bevorzugt. Bei gleicher Präferenz entscheidet der Zufall, über welchen Mail Exchanger die Mail ausgeliefert wird. Näheres hierzu findet sich in RFC974

CNAME-Records

CNAME-Records (Canonical Name Resource Record) definieren einen Alias zu einem offiziellen, kanonischen Hostnamen. Der CNAME-Record sollte der einzige Resource-Record sein, in dem der Alias erwähnt wird. Resource-Records, die einen Domainnamen enthalten (wie zum Beispiel NS- oder MX-Records) dürfen sich nicht des Alias bedienen, sondern müssen auf den offiziellen Hostnamen zurückgreifen. CNAME-Records lassen sich vor allem dann einsetzen, wenn der Hostname eines Rechners geändert werden soll. Der Alias kann dann auf den alten Namen verweisen und den Benutzern so die Umstellung erleichtern:
www-ebzi52 IN	CNAME 	ns.lfv.bwl.de.

HINFO-Records

HINFO-Records (Host Information Records) enthalten hostspezifische Daten wie etwa die Hardware des Rechners und sein Betriebssystem. Sind Leerzeichen in der Typbezeichnung erwünscht, so sind Anführungszeichen notwendig:

ns.lfv.bwl.de.	IN	HINFO	`Siemens Pro C6 Linux 2.036´ 
Aus Sicherheitsgründen verzichten viele Organisationen auf HINFO-Records in ihren Name-Servern. Sie sind zum ordnungsgemäßen Betrieb einer Domain auch nicht erforderlich.

TXT-Records

TXT-Records enthalten frei wählbaren Text. Auf einigen Systemen dient ihr Inhalt dazu, Verwaltungsdaten zu kodieren.

Alle Name-Server unterstützen die bislang erwähnten Resource Records. Für die folgenden gilt dies nicht, nur einzelne Implementationen stellen sie zur Verfügung.

Es gibt noch einige andere Records, die aber nur für spezielle Anwendungszwecke benötigt werden.