unbound ist ein ziemlich schmaler DNS-Resolver, der sich perfekt dafür eignet einen lokalen Resolver/Cache für das eigene Netz zur Verfügung zu stellen. Natürlich ist das Teil nicht so mächtig wie der bind, aber dafür schmaler und damit ressourcenschonender. Ich setze bei mir den unbound als Resolver auf jedem meiner DNS Server ein. So ist bind dafür zuständig authorativ für meine Zonen zu antworten und unbound erledigt die externen Auflösungen der Server selber.
Diese Trennung hat einen entscheidenden Vorteil wenn man seine Zonen mit DNSSec geschützt hat. Macht nämlich der bind, neben den authorativen Antworten, auch den Resolver, dann kann bind die DNSSec Signaturen bei Anfragen für die eigenen Domains nicht validieren. Das geht vom Prinzip von DNSSec her nicht, dass ein Resolver DNSSec validieren kann, wenn er selber authorativ für die angefragte Zone antwortet.

Im folgenden möchte ich kurz die Installation von unbound zeigen und eine einfache Basiskonfiguration erstellen. Zum Schluss erwähne ich noch kurz die Stolperfallen über welche ich geflogen bin

Die meisten Paketverwaltungen bieten bereits fertige Pakete für unbound. Man kann ihn sich jedoch auch sehr einfach aus den Quellen bauen.

Der normale apt-Zwei(Drei)satz

apt-get update
#ein Upgrade ist nie eine verkehrte Idee ;-)
apt-get upgrade
apt-get install unbound

Auch hier „the same procedure as every time“

#Updaten ist nie eine dumme Idee ;-)
yum update
yum install unbound

Bei FreeBSD geht es am schnellsten via die Ports in /usr/ports/ Als erstes sollte man sicherstellen, dann man eine gegen Heartbleed gesicherte OpenSSL Version hat. Sonst erst die Ports updaten und openssl bauen.

#Zuerst mal updaten, wie immer :-)
freebsd-update fetch
freebsd-update install
portsnap fetch update
 
#openssl bauen falls nötig
cd /usr/ports/security/openssl
make install clean
 
#und zum Schluss den unbound
cd /usr/ports/dns/unbound
make install clean

Auch das Bauen aus den Quellen ist recht einfach. Je nachdem muss man ebenfalls zuerst eine aktuelle Version von openssl-1.0.1g bauen. CentOS hat in 6.5 die Version 1.0.1e über yum.

cd /tmp
wget https://www.openssl.org/source/openssl-1.0.1g.tar.gz
tar xvzf ./openssl-1.0.1g.tar.gz 
cd ./openssl-1.0.1g
./config --prefix=/opt/openssl --openssldir=/opt/local/openssl shared
make
#der folgende Test darf keine Feher werfen
#sonst kein make install machen
make test
make install clean

–openssldir und –prefix sollten auf jeden Fall angegeben werden. Sonst wird in die default Pfade installiert und das wird das openssl der Paketverwaltung u.U. totschiessen!

cd /tmp
wget http://unbound.net/downloads/unbound-latest.tar.gz
tar xvzf ./unbound-latest.gz
cd ./unbound-VERSION
./configure --prefix=/opt/unbound
make install clean

Die ganze Konfiguration erfolgt zentral in einem File. Wenn man via Paketverwaltung installiert hat, dann meist /etc/unbound/unbound.conf

server:
#Anker für DNSSec
#wird per default installiert
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
#IP Adresse welche die Anfragen entgegennimmt
    interface: 127.0.0.1
#IP Adresse über welche mit der Aussenwelt (auch LAN) kommuniziert wird
    outgoing-interface: LAN.IP.ADDR
#nur localhost Anfragen erlauben
    access-control: 127.0.0.0/8 allow
#IPv4 anbieten
    do-ip4: yes
#Port
    port: 53
#kein IPv6
    do-ip6: no
#kein TCP da keine Zonentranfers
    do-tcp: no
#Optionen für das Caching
    prefetch: yes  
    prefetch-key: yes
#nur sinnvoll bei aktiviertem DNSSec
#hat den "Nachteil" dass wesentlich mehr Anfragen produziert werden
#für die Validierung der Antworten.
#letztlich wird für jede Anfrage mit DNSSEc bei den authorativen NS nachgefragt
    harden-referral-path: yes  
#diese Option erschwert das Cache-Poisoning
#es werden zufällig Zeichen Upper/Lower case gemacht
#es gilt aber als experimentell
    use-caps-for-id: yes

das ist eine Basiskonfig für ein System mit einem Resolver für den localhost

Kurz etwas zur letzten Option oben:
Das Einstreuen von Gross/Kleinschreibung bei den Anfragen soll für mehr Entropie sorgen. Ein korrekter Nameserver wird sowohl für example.tld als auch ExAMple.tld mit derselben IP Adresse antworten. Er schickt aber in seiner Antwort den angefragten Namen genau so wie er ihn erhalten hat. Damit kann der unbound dann feststellen ob die Antwort zu einer offenen Anfrage gehören kann (legitime Antwort) oder nicht (gespoofte Antwort meist mit dem Zweck den DNS-Cache zu verseuchen). Diese Option macht es einem Angreifer wesentlich schwieriger „korrekte“ Antworten erzeugen zu können, welche auf eine falsche IP-Adresse auflösen würden.
Mehr gibt's im RFC
Leider gibt es Nameserver welche mit solchen Anfragen nicht umgehen können. Da gibt es zwei Problemfälle

1. Server arbeiten zwar case-insensitive d.h. beantworten example.tld und ExApMLe.tld mit derselben IP, aber in ihren Antworten wird der Name nicht exakt so geschickt wie er erhalten wurde. Meist alles in Kleinbuchstaben
2. Server arbeiten komplett case-sensitive. Das ist eine Verletzung der RFC für DNS, aber es gibt solche Server d.h. sie antworten zwar mit dem korrekten Namen in der Antwort. Je nach Anfrage kommen aber unterschiedliche Antworten zurück z.B. wird nur example.tld zu einer IP aufgelöst ExAMplE.tld hingegen nicht (meist NXDOMAIN)
   

Ersteres verhindert die Erkennung gespoofter Pakete. Letzteres jedoch verunmöglicht eine Auflösung der Hostnamen, wenn dns-0x20 aktviert ist, komplett gute Beschreibung bei Google
Wenn man dieses Feature also aktiviert sollte man bei Problemen mit der Auflösung daran denken

Per default verwirft unbound Reverse Anfragen für lokale Netze nach RFC1918. Wenn man also DNS für's LAN braucht gibt es zwei Wege:

• Statische Einträge

    local-zone: "168.192.in-addr.arpa." static
    local-data-ptr "192.168.100.54 86400 meinHost.meinLan."
    local-zone: "meinHost.meinLan." static
    local-data: "meinHost.meinLan. IN A 192.168.100.54"

• Von einem authorativen Server abfragen

    local-zone: "168.192.in-addr.arpa." nodefault
    local-zone: "meinHost.meinLan.* nodefault
#aktivieren falls man dnssec-Validierung 
#auf dem Resolver aktviert hat
    insecure-domain: "meinHost.meinLan"
stub-zone:
    name: "168.192.in-addr.arpa."
    stub-addr: IP.ADDR.DNS.SRV
    stub-prime: no
stub-zone:
    name: "meinHost.meinLan"
    stub-addr: IP.ADDR.DNS.SRV
    stub-prime: no

Ich bevorzuge 2) weil ich eh den bind am laufen habe für meine Zonen (auch für's LAN). Das spart das doppelte Führen der IP/Namen. Aber jeder wie er/sie will

Für den unbound ist es von Vorteil (aus Sicht der Performance) für Anfragen nach extern Forward-Server zu definieren. Es ist aber nicht zwingend notwendig, da unbound ohne Forwarder sich einfach von der root-Zone zu der gesuchten Zone durchfragt.
Das dauert aber deutlich länger und kann zum Problem werden wenn verschiedene Dienste auf dem Server (z.B. Mailserver) viel DNS-Anfragen erzeugen und durch die langsameren Antwortzeiten des DNS ausgebremst werden.

forward-zone:
     name: "."
     forward-addr: 8.8.8.8
     forward-addr: 8.8.4.4

hier werden also die schnellen Google-DNS Server abgefragt für externe Anfragen. Ja ich weiss Google ist eine Datenkrake, aber sie haben nun mal die potentesten Server und antworten unter diesen beiden IPs immer extrem schnell. Alternativ kann man auch die NS des eigenen Providers eintragen.

Alle möglichen Konfigparameter werden hier beschrieben

Falls man bereits einen DNS Server einsetzt muss man diesen erst noch anpassen, damit unbound starten kann. Da unbound ja an 127.0.0.1 und Port 53 binden will, muss dieser erst freigemacht werden. Dazu muss man die 127.0.0.1 aus der listen-on port 53 Direktive entfernt werden z.B.

listen-on port 53 { LAN.IP.ADD.RES; };

nach einem service bind9 restart sollte sich service unbound start problemlos ausführen lassen.

Testet es am besten mit ein paar DNS Abfragen

dig @127.0.0.1 meinHost.meinLan
dig @127.0.0.1 -x 192.168.100.54
dig @127.0.0.1 google.ch

Wenn die Tests oben geklappt haben, kann man systemweit den Resolver anpassen. Dazu in /etc/resolv.conf als ersten Nameserver

nameserver 127.0.0.1
[alle anderen Nameserver]

eintragen

Zum Schluss also noch die Fettnäpfchen wo man reintreten kann.

• Das allerwichtigste voraus: bei Problemen das Log-Level hochdrehen und die Logs anschauen

server:
     verbosity: 2
     [Rest der Konfig]

• die Punkte (.) am Ende der Zonennamen sind keine Vertipper
• stellt bei local-zone immer sicher, dass sie entweder static oder nodefault sind
• Reverse Zonen für RFC1918 können nur so angelegt werden:
  1. 10.0.0.in-addr.arpa.
  2. 168.192.in-addr.arpa.
  3. 16.172.in-addr-arpa. (hier logischerweise das erste Oktett so anpassen, dass es für die eigene Umgebung passt)
• bei DS (DNSSec) Fehlern in den Logs unbedingt sicherstellen, dass die Zonen welche auf RFC1918 IP-Adressen auflösen, in insecure-domain eingetragen sind. Bei mehreren Domains den insecure-domain Eintrag einfach wiederholen
• als stub-zone können nur Zonen angelegt werden, bei denen stub-addr authorativ für die Zone antwortet. Andernfalls muss man die Zone(n) als forward-zone anlegen