Hallo!

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:

[...]
#
# Localhost
#
view "Localhost" {
   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 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.