Leider funktioniert ein Split-Name-Server-Setup so wie sie ihn beschreiben
auch mit BIND9 nicht.
Wenn mit "view" gearbeitet wird, müssen alle "zone"-Definitionen in einer
"view" eigeschlossen werden. Folgendes Setup:
named.conf:
options {
[...]
forwarders { 10.2.8.1; };
};
[...]
#
# Zone as seen in 10.2.107.0/24
#
view "Net-10.2.107" {
match-clients { any; };
zone "myhome.home" IN {
type master;
file "10.2.107/zone";
};
zone "107.2.10.in-addr.arpa" IN {
type master;
file "10.2.107/rev";
};
};
10.2.107/zone:
$ORIGIN mm.fiducia.de.
$TTL 1D
@ IN SOA @ root (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS @
localhost IN A 127.0.0.1
dns IN A 10.2.107.2
10.2.107/rev:
$ORIGIN 107.2.10.in-addr.arpa.
$TTL 1D
@ IN SOA localhost. root.localhost. (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS localhost.
2 IN PTR dns.myhome.home.
Abfrage mit "nslookup":
X:\>nslookup
*** Der Servername für die Adresse 10.2.107.2 konnte nicht gefunden
werden:
Non-existent domain
*** Die Standardserver sind nicht verfügbar.
Standardserver: UnKnown
Address: 10.2.107.2
offenbar kann sich der Nameserver jetzt selbst nicht finden...
Ergebnis: da ein "forward" definiert ist, wird dieser für _alle_ Anfragen
benutzt. Die eigenen Zonendefinitionen werden nie ausgewertet.
Einfügen einer "localhost"-Zone in die view liefert das gewünschte
Resultat:
[...]
#
# Zone as seen in 10.2.107.0/24
#
view "Net-10.2.107" {
match-clients { any; };
zone "localhost" IN {
type master;
file "127.0.0/zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0/rev";
allow-update { none; };
};
zone "myhome.home" IN {
type master;
file "10.2.107/zone";
};
zone "107.2.10.in-addr.arpa" IN {
type master;
file "10.2.107/rev";
};
};
Und hier die Abfrage:
X:\>nslookup
Standardserver: dhcp.mm.fiducia.de
Address: 10.2.247.2
Der Grund liegt in der Art und Weise, wie die Zone-Files aufgebaut sind:
die Definition bezieht sich in den "SOA"-Records auf "localhost" dieser
muß dann auch in _jede_ view mit aufgenommen werden. Die Alternative, im
"SOA"-Record den Namen des Nameservers anzugeben ist natürlich auch
möglich.
Wichtig ist eigentlich nur, daß wenn Views verwendet werden, alle Zonen in
Views eingeschlossen werden müssen, und jede dieser Views in sich
konsistent sein muss. Etwas wie:
zone "localhost" IN {
type master;
file "127.0.0/zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0/rev";
allow-update { none; };
};
};
#
# Zone as seen in 10.2.107.0/24
#
view "Net-10.2.107" {
match-clients { any; };
zone "myhome.home" IN {
type master;
file "10.2.107/zone";
};
zone "107.2.10.in-addr.arpa" IN {
type master;
file "10.2.107/rev";
};
};
Funktioniert leider nicht, auch wenn es Arbeit sparen könnte --- aber wozu
gibt es "$INCLUDE"?
Mit freundlichen Grüßen
Thomas Schweikle
PS: Views lassen sich übrigens auch an eine IP-Adresse oder an einen Port
binden. Das ist sehr praktisch wenn der Nameserver mehr als eine
Netzwerkkarte hat.
