Position: Home > Computer Know-How / Gewusst Wie > BIND caching Nameserver

BIND caching Nameserver

Nachdem ich vor einiger Zeit endlich begriffen habe, wie man BIND auf einem Linux-Internet-Gateway richtig einrichtet, will ich das hier mal erklären. Denn auch zu diesem Thema sind die vorhandenen Beschreibungen im Internet nicht so prächtig.

Einzig im Buch "Linux" von Herrn Kofler ist eine brauchbare Beschreibung, wenn die auch nicht zu 100% bei mir funktionierte.

Prinzipiell geht es darum, bei einem Gateway für zwei der drei festen IP-Zonen BIND richtig einzurichten. Die Zonen sind dabei das interne IP-Netz (127.0.0.0) und das Netz, auf welchen die Intranet-PCs auf das Gateway zugreifen (bei mir 192.168.11.0). Das externe Netz mit dynamischer IP vom Provider wird nicht konfiguriert.
Warum das so ist, weiß ich nicht, allerdings funktioniert es auch so wirklich perfekt, wie man an der Auflösegeschwindigkeit von IP-Adressen sieht.

Die modernen BIND-Varianten laufen im Allgemeinen in einem chroot-Käfig, das heißt, die Konfigurationsdateien liegen in diesem Verzeichnis und nicht mit allen anderen Konfigurationsdateien in "/etc".

Bei mir ist dieses Verzeichnis "/var/named/chroot".

In "/etc" gibt es einzig noch die Datei "resolv.conf". Hier steht für alle anderen Programme drin, welcher Rechner das DNS zur Verfügung steht. Bei uns steht also logischweise drin:

search klausi.home
nameserver 127.0.0.1
domain klausi.home

In "/var/named/chroot" gibt es entsprechende Unterverzeichnisse wie im normalen Root-Verzeichnis, also nochmal "etc" und "var/named". In "/var/named/chroot/etc" liegt die Haupt-Konfigurationsdatei von BIND, "named.conf" mit folgendem Inhalt:

options { 
	query-source address * port 53;
	directory "/var/named";
	listen-on { 127.0.0.1; 192.168.11.0/24; };
	forwarders {194.25.2.129; 194.25.2.130; 194.25.2.131;
	217.237.151.161; };
	notify no;
};
controls { 
	inet 127.0.0.1 allow { localhost; } keys { rndckey; };
	inet 192.168.11.1 allow { localhost; 192.168.11.0/24; }
	keys { rndckey; };
};
zone "." IN { 
	type hint;
	file "named.ca";
};
zone "localhost" IN {
	allow-update { none; };
	type master;
	file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" IN { 
	allow-update { none; };
	type master;
	file "named.local";
};
zone "11.168.192.in-addr.arpa" { 
	type master;
	file "11.168.192.in-addr.arpa.zone";
};
zone "klausi.home" IN { 
	type master;
	file "klausi.home.zone";
};
include	 "/etc/rndc.key";

Unter "options" steht unter anderem, welche Netze DNS nutzen dürfen ("listen-on") und wohin BIND Anfragen weiterleitet, die es selbst nicht beantworten kann ("forwarders"). Dort stehen bei mir diverse DNS-Server von T-Online. Hier geht Klasse vor Masse, das heißt, zwei Einträge reichen auch.

Auch unter "controls" werden nochmal die Netze, welche Netze DNS nutzen dürfen, definiert.

Danach werden drei Zonen definiert, das Internet (zone "."), das localhost-Netz (zone "localhost" und zone "0.0.127.in-addr.arpa") und das interne Netz (zone "klausi.home" und zone "11.168.192.in-addr.arpa"). Die letzten beiden Zonen doppelt, einmal fürs Vorwärts-Auflösen, einmal rückwärts.

Jede Zone hat noch eine eigene Konfigurationsdatei (jeweils "file"), wobei "named.ca" vom System fertig vorgegeben ist und eigentlich nicht aktualisiert werden muss (aber kann):

localhost.zone:

$TTL 86400
@		IN	SOA	@	root	(
				42 ; serial
				10800 ; refresh
				900 ; retry
				604800 ; expire
				86400 ) ; ttl
				
		IN	NS	@	
		IN	A	127.0.0.1

 

named.local:

$TTL 86400
@	IN	SOA	localhost.	root.localhost.	(
				1 ; serial
				28800 ; refresh
				14400 ; retry
				3600000 ; expire
				86400 ) ; ttl
				
		IN	NS	localhost.
1		IN	PTR	localhost.

 

11.168.192.in-addr.arpa:

$TTL 86400
@	IN	SOA	gateway.klausi.home.	root.klausi.home.	(
				43 ; serial
				28800 ; refresh
				14400 ; retry
				3600000 ; expire
				86400 ; ttl
				)
			IN	NS	gateway.klausi.home.
localhost	IN	A	127.0.0.1
gateway	IN	A	192.168.11.1	
defiant	IN	A	192.168.11.7

 

klausi.home.zone:

$TTL 86400
@	IN	SOA	gateway.klausi.home.	root.klausi.home.	(
				2 ; serial
				28800 ; refresh
				14400 ; retry
				3600000 ; expire
				86400 ; ttl
				)

		IN	NS	gateway.klausi.home.

1		IN	PTR	gateway.klausi.home.	
7		IN	PTR	defiant.klausi.home.

Wichtig ist, dass in jeder Datei ein Nameserver ("NS") definiert ist und doppelte Seriennummern ("serial") sollte man vermeiden. Ansonsten sollte ein Anpassen an eigene Verhältnisse einfach sein.

Zum Test nach einem Neustart des Dienstes sollte ein "host localhost" ohne Verzögerung z.B. ein "localhost.klausi.home has address 127.0.0.1" als Ausgabe erzeugen.

Weitere Informationen, teilweise redundant zu den Obigen:

 

DNS and BIND

LINUX