Dies ist die archivierte Version des Blogs vom 05.01.2017. Aktuelle Beiträge findest du unter thomas-leister.de
 

Meine Server verfügen seit ein paar Wochen über lokale, nur vom DNS Root abhängige DNS-Resolver, die auch DNSSEC beherrschen. Der Vorteil: DNS-Ergebnisse lassen sich lokal cachen und man muss weniger auf externe Infrastruktur vertrauen. Das verbessert Datenschutz und Sicherheit. Die DNS-Anfragen werden direkt an einen der DNS-Rootserver gestellt und von dort aus aufgelöst. Der kleine DNS-Resolver „Unbound“ ist perfekt als lokaler Resolver geeignet und mit wenigen Kommandos einsatzbereit:

apt install unbound

Eigentlich könnte die Anleitung an dieser Stelle schon fast zu Ende sein, denn nach der Installation horcht der Resolver lokal bereits auf Port 53 und beherrscht auch schon DNSSEC. Trotzdem sind wir noch nicht fertig, denn der Resolver bekommt jetzt noch eine aktualisierte Version des DNSSEC Root Trust Anchors:

unbound-anchor

… speichert neuen key in /etc/unbound/root.key

Die Datei /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf solltet ihr so anpassen:

server:
    auto-trust-anchor-file: "/etc/unbound/root.key"

(Hinweis zu Ubuntu 16.04: Bevor Unbound gestartet wird, muss noch ein kleiner Bug behoben werden: Unbound muss Zugriff auf sein Konfigurationsverzeichnis haben: chown unbound /etc/unbound/)

Unbound ist fertig eingerichtet und kann gestartet werden:

service unbound start

Damit der DNS-Server vom System genutzt wird, muss je nach Linux-Distribution die Netzwerkkonfiguration angepasst werden, sodass Unbound als DNS-Resolver genutzt wird. In meiner Konfiguration (/etc/network/interfaces) sieht das so aus:

auto lo
iface lo inet loopback
auto eth0

iface eth0 inet static
    address 5.1.76.155
    netmask 255.255.255.0
    gateway 5.1.76.1
    dns-nameservers 127.0.0.1 8.8.8.8 8.8.4.4

iface eth0 inet6 static
    address 2a00:f820:417::be19:7b23
    netmask 64
    gateway 2a00:f820:417::1
    dns-nameservers ::1 2001:4860:4860::8888 2001:4860:4860::8844

Ich habe euch blau markiert, wo ich eine Anpassung gemacht habe. In meinem Beispiel wird zuerst versucht, Unbound zu nutzen (steht an erster Stelle) – und wenn das nicht funktioniert, wird das Google DNS befragt. Neu einem Neustart wird die aktualisierte Netzwerkkonfiguration genutzt.

Wenn ihr wissen wollt, welchen Performance-Vorteil der lokale DNS-Cache bringen kann, führt zweimal hintereinander eine DNS-Anfrage aus:

dig thomas-leister.de | grep "Query time"

(evtl. Paket „dnsutils“ für „dig“-Kommando nach installieren). Die Query Time sollte beim zweiten Mal 0-1 ms betragen, während sie bei der ersten Anfrage deutlich höher liegt.


Post published on 17. Februar 2016 | Last updated on 17. September 2016
Tags:           

Diesen Blog unterstützen

Wenn Dir der Beitrag gefallen hat, freue ich mich über einen kleinen Obolus :-) Bitcoin QR Code

PayPal-Seite: https://www.paypal.me/ThomasLeister
Meine Bitcoin-Adresse: 15z8 QkNi dHsx q9WW d8nx W9XU hsdf Qe5B 4s

Siehe auch: Unterstützung

Informationen zum Autor

Thomas Leister

Geb. 1995, Kurzhaar-Metaller, Geek und Blogger. Nutzt seit Anfang 2013 ausschließlich Linux auf Desktop und Servern. Student der Automobilinformatik an der Hochschule für angewandte Wissenschaften in Landshut.

28 thoughts on “Lokalen DNS-Resolver und -Cache Unbound unter Ubuntu nutzen

  • Hi
    interessanter Artikel. Sehe ich das richtig, dass jeder Server und jeder PC in Deinem Netzwerk einen eigenen DNS-Cache hat?
    Wäre es da nicht sinnvoller einen zentralen Rechner (evtl. den DHCP / Gateway – Server) mit dem DNS-Cache zu versehen und die DHCP-Einstellungen entsprechend DNS anzupassen (evtl. anstatt 127.0.0.1 / 192.168.1.1)?

    • Hi,

      nur die Server verfügen bisher über einen eigenen Unbound-Server. Braucht kaum Ressourcen und ist maximal zuverlässig und sicher. Mit mehreren Servern oder PCs im Netzwerk würde mann dann vllt eher einen zentralen DNS Cache nehmen und den via DHCP bekannt machen. Bei meinen Servern verzichte ich bisher darauf, weil die Server in einem RZ stehen, dessen Netzwerk ich nicht uneingeschränkt vertrauen kann. In dem Fall ist es besser, wenn jeder Server seinen eigenen Cache hat.

      LG Thomas

  • Danke für den Artikel… Wird gleich mal bei mir eingerichtet :)
    Aber noch ein kleiner Hinweis: Es muss Ubuntu 16.04 und nicht Ubuntu 16.06 heißen.

  • Maximilian Senftleben

    Hast du unter 16.04 noch weitere Probleme? Z.B. mit dem Autostart von Unbound?

    Unbound funktioniert wie erwartet, und mittels „systemctl enable“ sollte er eigentlich auch automatisch nach einem Neustart starten, aber irgendwie schafft er es nicht und läuft nach ca 5min in einen Timeout:

    May 3 12:45:58 mail systemd[1]: Starting unbound.service…
    May 3 12:45:58 mail unbound[1036]: * Starting DNS server unbound
    May 3 12:50:58 mail systemd[1]: unbound.service: Start operation timed out. Terminating.
    May 3 12:50:58 mail systemd[1]: Failed to start unbound.service.
    May 3 12:50:58 mail systemd[1]: unbound.service: Unit entered failed state.
    May 3 12:50:58 mail systemd[1]: unbound.service: Failed with result ‚timeout‘.
    May 3 12:55:01 mail unbound-anchor: /var/lib/unbound/root.key has content
    May 3 12:55:01 mail unbound-anchor: success: the anchor is ok

    Wenn ich den Service dann mittel „systemctl start unbound“ manuell starte, dann klappt alles:

    May 3 12:58:32 mail systemd[1]: Starting unbound.service…
    May 3 12:58:32 mail unbound[1268]: * Starting DNS server unbound
    May 3 12:58:34 mail unbound-anchor: /var/lib/unbound/root.key has content
    May 3 12:58:34 mail unbound-anchor: success: the anchor is ok
    May 3 12:58:34 mail unbound: [1284:0] notice: init module 0: validator
    May 3 12:58:34 mail unbound: [1284:0] notice: init module 1: iterator
    May 3 12:58:34 mail unbound: [1284:0] info: start of service (unbound 1.5.8).
    May 3 12:58:34 mail unbound[1268]: …done.
    May 3 12:58:34 mail systemd[1]: Started unbound.service.

    Das problem scheint zu sein, dass das Networkinterface nicht schnell genug verfügbar ist und dann Unbound nicht weiter weiß.
    Bei einem ähnlichen Problem wurde wohl empfohlen falls der NetworkManager verwendet würde den Service „systemctl enable NetworkManager-wait-online.service“ zu aktivieren, da es bei mir allerdings nur „systemd-networkd-wait-online.service“ hab ich es damit versucht, scheint aber auch nicht zu gehen.

    Als Alternative bleibt wohl ein Skript in /etc/rc.d

    Hast du da noch Ideen, bzw wie hast du den Autostart geregelt, falls überhaupt

  • Hallöle,

    Du hast ja im Post bzgl. Postfix und Spamhaus [1] geschrieben, das der/die Google-DNS die Domain(s) von Spamhaus nicht auflöst und auf unbound verwiesen.

    Allerdings weiss ja unbound vorerst genausowenig über (bspw.) zen.spamhaus.org und stellt die Anfrage an den Google-DNS, der den A-Eintrag ebensowenig kennt/kennen will.

    Somit hilft doch unbound auch nicht dabei, diese Domain aufzulösen.
    Oder hab ich da etwas falsch verstanden?

    • Das hast du falsch verstanden ;-)

      unbound befragt nicht das Google-DNS, sondern direkt die DNS-Rootserver (Und dann kaskadierend die jeweiligen Nameserver der Domain und Subdomain). Dein Unbound ersetzt die Google-Resolver (die du vllt vorher verwendet hast) vollständig. Unbound ist also nicht nur Cache, sondern vollwertiger Resolver.

      LG Thomas

      • Ok. Danke für die Aufklärung.

        Scheinbar hab ich mich dann irgendwie zu glatt angestellt.
        Denn nachdem ich unbound installierte und die 127.0.0.1 an erster Stelle meiner resolv.conf eintrug, konnte zen.spamhaus.org noch immer nicht aufgelöst werden. (unknown host)
        An zweiter und dritter Stelle standen die beiden Google-DNS 8.8.8.8 und 8.8.4.4

  • Moin Thomas,
    nach einigen Recherchen und Tricksereien mit Unbound ist mir aufgefallen, dass es wohl Probleme mit IPv6 und Ubuntu 16.04 gibt. Ob dieses Problem auch mit anderen Distributionen auftritt, weiß ich nicht :)

    Zumindest muss in Unbound IPv6 deaktiviert werden. Ich habe dazu folgende Konfiguration genutzt:

    server:
    auto-trust-anchor-file: „/etc/unbound/root.key“

    interface-automatic: yes
    port: 53
    do-ip4: yes
    do-ip6: no
    do-tcp: yes
    do-udp: yes
    do-daemonize: yes
    username: „unbound“
    use-syslog: yes

    access-control: 127.0.0.1/24 allow
    access-control: 0.0.0.0/0 deny

    local-zone: „domain.de.“ transparent
    local-data: „www.de.de. 3600 IN A 127.0.0.1“

    forward-zone:
    name: „.“
    forward-addr: 8.8.8.8

    Mit dieser Konfiguration hat es dann auch bei mir geklappt :)

    Viele Grüße,
    Lukas
    forward-addr: 8.8.4.4

  • Hey Thomas,
    hast du nen Tipp um einen DNS Resolver öffentlich zu betreiben, also das alle Ihn ohne logging benutzen können?

    -Maxi

  • Hallo Thomas,
    danke für den Artikel. Auf eine Unschönheit möchte ich aufmerksam machen. Unbound wird bereits im kürzlich erschienenen Ubunutu 16.04 schon nicht mehr gewartet. Das zeigt der ubuntu-support-status. D.h. Unbound erhält automatisch keine Sicherheitsupdates, was ich bei einem Resolver als bedenkenswert einstufe. Vielleicht gibt es eine bessere und genauso schlanke Alternative?

  • ubuntu-support-status ist bei 16.04 nicht mehr zuverlässig, siehe https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670

  • das muss apt-get unbound heißen ;)

  • Hallo Thomas,
    nice article.
    Wie soll die Netzwerke Konfigurationen bei „Virtual Server“ aussehen? Bei mir sieht so aus:

    auto lo
    iface lo inet loopback

    auto venet0:0
    iface venet0:0 inet static
    address xx.xxx.xx.xx
    netmask 255.255.255.255

    auto venet0:3
    iface venet0:3 inet static
    address xx.xxx.xx.xx
    netmask 255.255.255.255

  • Wie kann ich das umändern?
    Damit der DNS-Server vom System genutzt wird, muss je nach Linux-Distribution die Netzwerkkonfiguration angepasst werden, sodass Unbound als DNS-Resolver genutzt wird. In meiner Konfiguration sieht das so aus:

    • Ich möchte mich auch erkundigen in welcher datei muss ich das ändern?

      • Ich glaube in /etc/network/interfaces aber das soll Thomas nochmal absegnen.
        PS: Bei mir sieht das falsch aus.

        auto lo
        iface lo inet loopback

        # Auto generated venet0 interface
        auto venet0
        iface venet0 inet manual
        up ifconfig venet0 up
        up ifconfig venet0 127.0.0.2
        up route add default dev venet0
        down route del default dev venet0
        down ifconfig venet0 down

        iface venet0 inet6 manual
        up ifconfig venet0 add MEINE IPv6 HIER/64
        down ifconfig venet0 del MEINE IPv6 HIER/64
        up route -A inet6 add default dev venet0
        down route -A inet6 del default dev venet0

        auto venet0:0
        iface venet0:0 inet static
        address MEINE IPv4 HIER
        netmask 255.255.255.255

  • Statt /etc/network/interfaces habe ich die Zeile

    nameserver 127.0.0.1

    in die Datei

    /etc/resolvconf/resolv.conf.d/tail

    eingefügt.
    Das scheint auch zu funktionieren:

    dig thomas-leister.de | grep „Query time“
    ;; Query time: 335 msec
    dig thomas-leister.de | grep „Query time“
    ;; Query time: 0 msec

  • Hi Thomas,

    vielen Dank für diesen Artikel. Da dig oftmals nicht bei den Minimalinstallationen dabei ist, wäre es vielleicht noch einmal sinnvoll zu erwähnen, wie und von wo dig (enthalten in dnsutils) bezogen werden kann. Das wäre nur ein Vorschlag meinerseits. :)

    Beste Grüße
    — Florian

  • 1. Also Nameserver werden seit meiner ersten Slackware vor über 20 Jahren und der aktuellen Ubuntu 16.04 immer noch in der */etc/resolv.conf* eingetragen! Diese sind immer vor allen Network-Interfaces dort einzutragen! Falls bei Ubuntu du die interfaces nutzt, wo man nicht begehen soll, muss resolvconf installiert werden.

    2. Ein lokaler DNS-Server auf einem relativ langsamen, gemieteten Server, kommt niemals an die Performance der Nameserver deines Hosters oder der hiesigen Server-Farmen von Google und Co. heran! Nie und nimmer.

    3. Wenn du zweimal hintereinander in kurzem Abstand eine Domain über einen Nameserver auflöst… tara! Schlägt der Cache an, und sagt: Hey, die IP hatten wir gerade, bitte schön! Wie in deinem Browser, der hat auch internen eine DNS-Cache…

    Beispiel (kalt nicht im DNS-Cache) mit unbound lokal:

    dig linux.org

    ; <> DiG 9.10.3-P4-Ubuntu <> linux.org
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60949
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;linux.org. IN A

    ;; ANSWER SECTION:
    linux.org. 3600 IN A 104.225.135.13

    ;; Query time: 307 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Mon Sep 19 18:21:49 CEST 2016
    ;; MSG SIZE dcvd: 54

    Eierlangsam… nicht der Rede wert. Absolute Bremse.

    Jetzt mit dem DNS-Servers des Webshosters, hier STRATO (kalt nicht im DNS-Cache):

    dig enlightenment.org

    ; <> DiG 9.10.3-P4-Ubuntu <> enlightenment.org
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15320
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;enlightenment.org. IN A

    ;; ANSWER SECTION:
    enlightenment.org. 3600 IN A 140.211.167.135

    ;; Query time: 32 msec
    ;; SERVER: 85.214.XXX.XXX#53(85.214.XXX.XXX)
    ;; WHEN: Mon Sep 19 18:27:18 CEST 2016
    ;; MSG SIZE rcvd: 51

    Das ist eine vernünftige Antwortzeit: 32ms sind ok.

    Jetzt noch einmal sofort dieselbe Auflösung:

    dig enlightenment.org

    ; <> DiG 9.10.3-P4-Ubuntu <> enlightenment.org
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61785
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;enlightenment.org. IN A

    ;; ANSWER SECTION:
    enlightenment.org. 3490 IN A 140.211.167.135

    ;; Query time: 0 msec
    ;; SERVER: 85.214.XXX.XXX#53(85.214.XXX.XXX)
    ;; WHEN: Mon Sep 19 18:29:08 CEST 2016
    ;; MSG SIZE rcvd: 51

    Also: apt-get –purge remove unbound

  • Auf einem frisch aufgesetzten Ubuntu 16.04 startet bei mir unbound mit der beschriebenen Methode nicht automatisch beim Systemstart, daher habe ich mich auf die Suche begeben und herausgefunden, dass man den Passus

    service unbound start

    folgendermaßen ändern kann…
    Zunächst erstellt man eine Datei /etc/default/unbound mit folgendem Inhalt:

    DAEMON_OPTS=“-c /etc/unbound/unbound.conf“

    Danach bindet man unbound in den Systemstart mittels

    systemctl enable unbound

    ein und startet dann unbound mittels

    systemctl start unbound

    Danach sollte auch nach jedem Systemneustart (und nicht nur in der aktuellen Session) der Aufruf

    dig +dnssec A http://www.dnssec.cz | grep ad

    ein Ergebnis geben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.