bind9 - was beachten?

[mrserious]

Hallo,

betreibe für mich hier zu hause bind9 als lokalen DNS-caching-server.
Besonders konfiguriert habe ich ihn dazu nicht. Einfach installiert, per DHCP an die einzelnen Clients verteilt und... läuft!

Nun möchte ich in einem mittelgroßen Netz (etwa 150 Clients) den bisherigen DNS-Server durch eine VM ersetzen, in der wiederum Debian mit bind9 laufen soll.
Ebenfalls als einfaches Caching-System (hauptsächlich, damit der Internetrouter nicht überlastet wird).
Muss ich dabei etwas beachten? Habt ihr Tipps für mich? Speziell was die Sicherheit des Systems angeht?

Grüße und morgen einen guten Rutsch

[dufty2]

Ja, bind9 rausschmeissen und durch pdns-recursor aut simile ersetzen.

[mrserious]

Guten Morgen

ok.... weil?

[dufty2]

rekursiv - weil man selber auflösen will und nicht dem Internetrouter-Betreiber/DSL(?)-Provider überlassen will
und nicht bind9 - weil das Teil in der Vergangenheit durch hervorrangende Sicherheit hervortrat (hüstel, hüstel).

[rendegast]

Auf den linux-Maschinen vielleicht nscd,
auf den win-Maschinen dürfte die Entsprechung 'DNS-Client' per default aktiviert sein.

[Dimejo]

Ja, bind9 rausschmeissen und durch pdns-recursor aut simile ersetzen.

unbound war bei meinen Tests deutlich ressourcenschonender und schneller als PowerDNS.

[dufty2]

Ja, bind9 rausschmeissen und durch pdns-recursor aut simile ersetzen.

unbound war bei meinen Tests deutlich ressourcenschonender und schneller als PowerDNS.

Yo, das ist sicher eine gute Empfehlung, denn OpenBSD verwendet auch unbound AFAIK.

[mrserious]

Hm, was Performance angeht kann ich mich über bind nicht beklagen.
Da müsste ich allenfalls noch mosern, der DNS-Server meines Providers sei nicht der schnellste (ja, ein Umstieg auf Google-DNS wär ne Option).

Euer Tipp also: Weg von bind und hin zu unbound?

Wundert mich ein wenig. Dachte immer, bind sei DER Standard bei DNS-Servern. Und offen gestanden war mir garnicht bewusst, dass es da ernsthafte Alternativen gibt.

[dufty2]

Also schrieb ich "rekursiv", d. h. ohne forwarding
D. h. Dein unbound wird die root-DNS-Server selber "abklappern" und sich nicht auf die Forwarder - die DNS-Caches Deines Providers (oder Google-DNS oder OpenDNS oder sonstwen), welche quasi als Proxy agieren - verlassen.

[mrserious]

Hm, damit ließe sich an der Performance natürlich schrauben
Dauern die Abfragen selbst dann aber nicht länger?

[dufty2]

Das ist der Preis, den man zu zahlen hat für die Freiheit von den Datenkraken!
Und die eine Sekunde werdet Ihr auch schon überleben

[mrserious]

Ok, habe unbound mal in einer Testumgebung installiert.
Aber: Mein Testclient kann jetzt keine DNS-Abfragen mehr machen... bzw. erhält bei einem Ping z.B. nur "Unknown host".

Muss ich unbound als einfachen Caching-Server noch konfigurieren?


Edit:
Ok, habe darauf eine Antwort in einem einfachen Tutorial gefunden

Nächste Frage: Der DNS-Dienst soll wie gesagt auf einem V-Server laufen.
Welchen DNS trage ich denn dann auf dem V-Server selbst ein? Oder verweise ich quasi auf Localhost und unbound holt sich automatisch alles weitere von den root-DNS-Servern? Denn ansonsten würde er ja den DNS-Server meines Providers nutzen.

[dufty2]

Yep, da steht er selbst drin:

Code: Alles auswählen

$ cat /etc/resolv.conf
nameserver 127.0.0.1

oder wenn Du auf allen Maschinen die gleiche Config haben willst:

Code: Alles auswählen

$ cat /etc/resolv.conf
nameserver 192.168.1.13

Code: Alles auswählen

$ tail -7 /etc/unbound/unbound.conf
interface: 192.168.1.13
access-control: 192.168.1.0/24 allow
do-ip6: no
hide-identity: yes
hide-version: yes
remote-control:
        control-enable: no

[mrserious]

Also ich hab's grad nur mal kurz getestet, aber da zumindest lief es auf den Clients nicht...
Obwohl ich andere Probleme (Firewall etc.) ausschließen konnte.
Insbesondere hatte ich auf dem DNS-Server selbst dann nicht mehr die Möglichkeit, DNS-Abfragen zu stellen.
Hatte in der resolv.conf also 127.0.0.1 eingetragen und danach lief es nicht mehr.
Auch die ACL-Regeln hatte ich - so meine ich zumindest - für die Subnetze und Interfaces richtig eingetragen.

Werde das nachher nochmal in Ruhe testen, aber so zumindest funktionierte es vorerst nicht.


EDIT:

So, hab's gerade nochmal probiert, extra sämtliche iptables-Regeln ausgeschaltet etc.... funktioniert nicht.
Der DNS-Server selbst ist nicht in der Lage, irgendetwas aufzulösen. Genauso sieht's dann natürlich auch auf den Clients aus.

[dufty2]

Also, die Default-Einstellung ist

Code: Alles auswählen

interface: 127.0.0.1
access-control: 127.0.0.0/8 allow

auch wenn dies nicht so explicit in der /etc/unbound/unbound.conf steht.

Erlaubt's Du nun - per explicites Eintragen in jener - das Lauschen auf eth0, in etwa per

Code: Alles auswählen

interface: 192.168.1.13

ist die tatsächliche Konfig nun

Code: Alles auswählen

interface: 192.168.1.13
access-control: 127.0.0.0/8 allow

=> d. h., er lauscht nun auf eth0 und _nicht_ mehr auf localhost, aber erlaubt (zum Abfragen) hast localhost aber _nicht_ eth0.

Ergo musst Du anpassen zu

Code: Alles auswählen

interface: 192.168.1.13
access-control: 192.168.1.0/24 allow

damit Du auch vom DNS-Server selbst aus per
dig @192.168.1.13 ....
abfragen kannst, (denn dig @localhost geht ja jetzt nicht mehr).
Daher kannst Du gleich auch auf dem DNS-Server in die /etc/resolv.conf reinschreiben
nameserver 192.168.1.13
denn dann reicht Dir wieder ein einfaches
dig heise.de
(also ohne "@...").

[mrserious]

Ja ganz genau, habe das Problem auch soeben gelöst, aber du warst schneller als ich
Habe localhost in der config allerdings drin gelassen. Das dürfte ja keine Probleme bereiten und ist mir intern übersichtlicher.

Vielen Dank für deine Hilfe!