Lokalen Nameserver einrichten

[Uhu U. (uhu)]

Was ich machen will:

Auf einem virtuellen Ubuntu 12.04 Server soll bind9 so eingerichtet 
werden, daß er nur für Subdomänen auf der VM zuständig ist und für 
DNS-Anfragen z.B. nach hp.server die IP-Adresse von server - also seine 
eigene - zurück gibt.

Was ich gemacht habe:
Zunächst bind9 auf server installiert. Anschließend waren folgende 
Dateien im Verzeichnis /etc/bind:

bind.keys
db.0
db.127
db.255
db.empty
db.server
db.local
db.root
named.conf
named.conf.default-zones
named.conf.local
named.conf.options
rndc.key
zones.rfc1918

db.server hat folgenden Inhalt:

;; db.server   
;; Forwardlookupzone für server   
;;
$TTL 2D
@       IN      SOA     server.workgroup. mail.workgroup. (
                        2006032202      ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                4W      ; Expire
                                3H )    ; NX (TTL Negativ Cache)

@                               IN      NS      server.workgroup.
                                IN      A       172.30.5.40

server                          IN      A       172.30.5.40
localhost                       IN      A       127.0.0.1

# Weitere A-Records für Rechner aus dem LAN entfernt

Um eine Domäne hp anzulegen, habe ich folgende beiden Zeilen angefügt:

hp                              IN      NS      server.workgroup.
hp.server                       IN      A       172.30.5.40

Nur leider gehts so nicht. Ein Test mit named-checkzone bringt Fehler:

$ named-checkzone server /etc/bind/db.server
zone server/IN: hp.server/NS 'server.workgroup' (out of zone) has no addresses records (A or AAAA)
zone server/IN: loaded serial 2006032202
OK

Muß für hp eine weitere Zonendatei angelegt werden, oder was ist da 
faul?

[JA (Gast)]

> Muß für hp eine weitere Zonendatei angelegt werden, oder was ist da
> faul?

Ja

[(prx) A. K. (prx)]

Dieses File ergibt nur Sinn, wenn man annimmt, dass es für die Domain 
"workgroup." zuständig ist. Denn nur dann wird der Name in den NS 
Records aufgelöst. Dein NS Record für "hp" definiert darin dann eine 
Subdomain "hp.workgroup." und das A Record für "hp.server" definiert die 
Adresse von "hp.server.workgroup.".

Soll die Domain "workgroup." wirklich definiert werden? Oder ist das 
eine nicht ganz geglückte Adaption eines Demo-Files?

[Uhu U. (uhu)]

A. K. schrieb:
> Soll die Domain "workgroup." wirklich definiert werden?

Die Workgroup ist die Domäne, in der sich das LAN befindet. Die wird von 
Ubuntu bei der Installation vorgeschlagen und ich habe sie einfach 
akzeptiert - bisher hat sie nicht gestört.

> Oder ist das eine nicht ganz geglückte Adaption eines Demo-Files?

Nein, das ist von der Installationsroutine von bind erzeugt worden und 
ich habe nur die Definitionen weiterer Rechner im LAN gelöscht.

[(prx) A. K. (prx)]

Wenn du auf "workgroup." verzichten kannst, dann mach das draus:

$TTL 2D
@       IN      SOA     hp.server. mail.server. (
                        2013121901      ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                4W      ; Expire
                                3H )    ; NX (TTL Negativ Cache)

@                               IN      NS      hp.server.

hp                              IN      A       172.30.5.40

Dort wo bisher sowas wie
  zone "workgroup" {
        type master;
        file "/etc/bind/db.server";
  };
steht muss nun
  zone "server" {
rein.

Es ist nicht immer zwingend, aber höflich, die Serial zu aktualisieren, 
wenn man das File ändert.

Brauchst du auch das "workgroup." (evtl. wg. Samba), dann gibts 2 
Zonefiles. Geschickterweise heisst das für "workgroup." dann db.server 
und das für "server." db.workgroup. ;-)

[Uhu U. (uhu)]

A. K. schrieb:
> Es ist nicht immer zwingend, aber höflich, die Serial zu aktualisieren,
> wenn man das File ändert.

Ich weiß, aber so lange ich hier im LAN rumwurstel und noch auf keinem 
grünen Zweig bin, ist das zu verschmerzen.

> Dort wo bisher sowas wie
>   zone "workgroup" {
>         type master;
>         file "/etc/bind/db.server";
>   };

So eine Anweisung gab es biher nicht. Merkwürdig, denn die im LAN 
präsenten Rechnernamen hat sich die Installationsroutine irgenwo 
beschafft - in der /etc/hosts des Servers standen sie jedenfalls nicht.

Und jetzt funktioniert im server ein "ping hp.server" - die Subdomäne 
ist also eingerichtet.

Als nächsten Test habe ich in einem weiteren virtuellen Linux die 
172.30.5.40 in /etc/network/interfaces als weiteren Dnsnameserver 
eingetragen und das Netzwerk neu gestartet.

ping hp.server aus der zweiten VM schlägt fehl mit "unkown host 
hp.server"

A. K. schrieb:
> Brauchst du auch das "workgroup." (evtl. wg. Samba), dann gibts 2
> Zonefiles. Geschickterweise heisst das für "workgroup." dann db.server
> und das für "server." db.workgroup. ;-)

Samba zickt ziemlich übel rum und ich benutze es ddeswegen nicht. Die 
Workgroup gab es aber schon vor der Samba-Installation.

[(prx) A. K. (prx)]

Uhu Uhuhu schrieb:
> Als nächsten Test habe ich in einem weiteren virtuellen Linux die
> 172.30.5.40 in /etc/network/interfaces als weiteren Dnsnameserver
> eingetragen und das Netzwerk neu gestartet.

Eine negative Antwort ist auch eine Antwort. "zusätzlich" bringt also 
nichts.

[Uhu U. (uhu)]

A. K. schrieb:
> Schreib es lieber in /etc/resolv.conf rein.

Das hat der Netzwerk-Neustart schon besorgt.

[Uhu U. (uhu)]

A. K. schrieb:
> Eine negative Antwort ist auch eine Antwort. "zusätzlich" bringt also
> nichts.

Jawoll, jetzt gehts...

[Uhu U. (uhu)]

So, der nächste Streich wäre, die ganze Chose so einzurichten, daß der 
bind auf einem Strato-Server laufen kann und dem Subdomänen beibringt.

Gehe ich recht in der Annahme, daß man Rekursion in dem Fall vermeiden 
kann und Forwarding auf die Strato-Nameserver einrichtet?

[(prx) A. K. (prx)]

Uhu Uhuhu schrieb:
> Gehe ich recht in der Annahme, daß man Rekursion in dem Fall vermeiden
> kann und Forwarding auf die Strato-Nameserver einrichtet?

Da habe ich grad nicht den Überblick.

Allerdings ist Rekursion nicht zwingend ein Problem, wenn man den NS so 
dressiert, dass er in der globalen Konfiguration nur bestimmte IPs (1) 
als Clients zulässt. In den Configs der autoritativen Zones lässt man 
dann den Rest der Welt zu.

Das führt dazu, dass die IPs in (1) ihn mit Rekursion als 
Cache/Forwarder für alle Domains nutzen können und er bei allen übrigen 
Anfragenden nur auf die autoritativen Domains reagiert.

[Uhu U. (uhu)]

Meinst du solche Einstellungen, wie hier: 
https://wiki.debian.org/Bind9#File_named.conf.options ?

[(prx) A. K. (prx)]

Ja.

acl "internal" {
   { 10/8; 172.16/12; 192.168/16; };
};

options {
   ...
   allow-query { internal; localhost; };
   ...
}

Und in die zone "xxx" { } Statements autoritativer Domains schreibt man 
zusätzlich
   allow-query { any; };

Bei Anfragen aus "internal" ist der Nameserver dann als Cache einsetzbar 
(muss kein forwarder sein). Auf Anfragen aus anderen Netzen reagiert er 
jedoch nur, wenn seine autoritativen Zones gefragt sind.

[Uhu U. (uhu)]

Auf dem Starto-Server würde der localhost ausreichen; die acl kann man 
sich dann sparen, denn dort gibt es ja kein aus Sicht meines Servers 
internes Netz mit anderen Rechnern.

Und dann könnte man auch gleich noch DynDNS dazu basteln - dann muß ich 
mich nicht mehr mit den Schikanen von dyn.com rumärgen.