ich hab hier grad 'n Verstaendnisproblem und hoffe ihr koennt mir helfen. Ich moechte in einem 172.16.0.0/16 Netz einen DNS-Server (BIND9) aufbauen in Verbindung mit einem DHCP-Server (ISC). Der DHCP-Server soll seine Leases an 172.16.200.1-254 vergeben. Die DDNS Updates der DHCP-Clients soll in eine eigene Zone erfolgen. Wenn ich mir dieses Tutorial durchlese (http://www.debianadmin.com/howto-setup- ... ebian.html) dann verwendet der Autor zwei Interfaces weil er noch am WAN angeschlossen ist. Das ist in meinem Falle anders, aber auch nicht das Problem, da nur ein Interface zum Einsatz kommt. Zum hauptsaechlichen Problem...
der Author beschreibt, wie er eine dyn.example.org verwendet und dann fuer all die fixen IPs nimmt er eine extra Zone namens static.example.org. Ich wuerde hier gerne fuer die dynamischen DHCP-Clients quasi die Zone dhcp.example.org verwenden, und fuer alle anderen die normale example.org verwenden, und nicht static.example.org. Ich bin mir aber nicht sicher, ob das dann zu Problemen fuehrt oder gar funktionieren kann, weil ja dyn.example.org in example.org enthalten ist, quasi wie eine subdomain ?
Damit verbunden wuesste ich auch nicht wie ich entsprechend mit nur zwei Zonen auskommen sollte. Ich hab das also entsprechend meinem Anliegen wie folgt geschrieben. Achtet dabei auf meine reversezone, für die ich den Namen so gewählt habe, damit es ein 16er bit netmask darstellt.
/etc/bind/named.conf.local
Code: Alles auswählen
[...]
# meine Hauptzone fuer alle statischen Hosts
zone "example.org" {
type master;
file "/var/cache/bind/forwardzone.example.org";
};
# die reverse-Zone für alle statischen Hosts
zone "16.172.in-addr.arpa" {
type master;
notify no;
file "/var/cache/bind/reversezone.172.16";
};
#die forwardzone für alle DHCP-Clients (DDNS dynamische also)
zone "dhcp.example.org" {
type master;
file "/var/cache/bind/forwardzone.dhcp.example.org";
allow-update { key "meinschluessel"; };
};
#die reversezone für alle DHCP-Clients (DDNS)
zone "200.16.172.in-addr.arpa" {
type master;
notify no;
file "/var/cache/bind/reversezone.172.16.200";
allow-update { key "meinschluessel"; };
};
forwardzone.example.org
Code: Alles auswählen
$ORIGIN .
$TTL 604800 ; 1 week
example.org IN SOA derhostname.example.org. hostmaster.derhostname.example.org. (
2011012191 ; serial
28800 ;refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
39600 ; minimum (11 hours)
)
NS derhostname.example.org.
$ORIGIN example.org
server1 A 172.16.1.1
server2 A 172.16.1.2
server-ug1 A 172.16.0.1
muster A 172.16.69.100
muster4 A 172.16.200.5
reversezone.172.16
Code: Alles auswählen
$ORIGIN .
$TTL 604800 ; 1 week
16.172.in-addr.arpa IN SOA derhostname.example.org. hostmaster.derhostname.example.org. (
2011012191 ; serial
28800 ;refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
39600 ; minimum (11 hours)
)
NS derhostname.example.org.
$ORIGIN 16.172.in-addr.arpa.
1.1 PTR server1.example.org.
2.1 PTR server2.example.org.
1.0 PTR server-ug1
100.69 PTR muster
5.200 PTR muster4
scheint zu funktionieren, so wie ich's geschrieben habe. Habs grad getestet mit der Forward und Reverse Zone forwardzone.example.org und reversezone.172.16 --> sieht gut aus... haette ich nicht gedacht, aber nun gut. Wenns so funktioniert, wieso nicht 
werd jetzt noch schauen wie sich das mit den DDNS verhaelt