unbound verweigert OpenDNS u.ä.

[Helianthus]

Hallo,

unbound macht leider was er will. Dabei möchte ich doch nur, dass er nicht die Nameserver meines Providers nutzt, sondern freie:

Code: Alles auswählen

 forward-zone:
      name: "."
  forward-addr: 208.67.222.220 # OpenDNS
  forward-addr: 208.67.222.222 # OpenDNS
# forward-addr: 195.50.140.114 # Vodafone
# forward-addr: 195.50.140.252 # Vodafone

eigentlich lief das hervorragend, bis ich mit

Code: Alles auswählen

#sei etwas gesprächig
verbosity: 2
#schreibe nicht nach
use-syslog: no
#sondern nutze
logfile: /var/log/unbound.log

das Log einstellte. Und siehe da, der Schlingel fragt einfach beim Router (192.168.0.1). Der aber leitet direkt an den Provider weiter.

Code: Alles auswählen

[] unbound[] info: reply from <.> 192.168.0.1#53
[] unbound[] info: query response was ANSWER

Aber noch bin ich Herr im Haus, also verbiete ich unbound die Anfrage beim Router:

Code: Alles auswählen

do-not-query-address: 192.168.0.1

Doch jetzt ist unbound geschnappt. Ein beispielsweise dig startpage.com braucht schlappe 4228 msec. Ich hatte gedacht, unbound würde das Surfen eher beschleunigen. Aber nicht, dass ich mir zwischen jeder Abfrage einen Kaffee holen kann. Im Log ist keine einzige Anfrage an die von mir eingestellten DNS-Server 208.67.222.220 oder 208.67.222.222 (diese sind aber erreichbar, sie liefern eine schnelle ping-Antwort). Nachdem unbound richtig MByte ins Log geschrieben hat findet er endlich die Antwort bei 192.112.36.4 und kann startpage.com auflösen. 192.112.36.4 ist ein Root-Nameserver. Wie zum Geier kommt das Vieh auf die Idee, einen Rootserver anzufragen? Ich habe folgende Zeilen auskommentiert!

Code: Alles auswählen

# auto-trust-anchor-file: "/var/lib/unbound/root.key"
# root-hints: "/var/lib/unbound/root.hints"

Abgesehen davon fragt er auch mit diesen Zeilen einfach beim Router nach. Die resolv.conf lautet nameserver 127.0.0.1.

Wie überredet man unbound, ganz normal einen anderen DNS-Server abzufragen? Und das in einer vernünftigen Zeit? Kennt jemand eine funktionierende unbound.conf? Zu Cachen und mit meiner Block-Liste abzugleichen macht er ja gut.

[dufty2]

Willkommen im Forum!

Welche unbound- bzw. debian-version verwendest Du?

Die "root.hints" werden - wenn ich micht recht erinnere - mit einkompiliert,
ein auskommentieren bringt da nichts, es sei denn, Du möchtest eine andere "root.hints" benutzen,
dann kann man die angeben.

Bei meiner Config habe ich kein "forward-"Statement und benutze so immer die root-server.
Das dauert natürlich länger, aber "OpenDNS" kann man wirklich vertrauen?
Würde da eher auf
213.73.91.35 # dnscache.berlin.ccc.de
85.214.20.141 # digitalcourage
setzen, _falls_ ich nicht die root-server(-kaskade) verwenden möchte.

Warum er allerdings Deine 192.168.0.1 (das ist Deine Default-Gateway, richtig?) befrägt,
würde mich auch interessieren.
Scheinbar hat er das "Default-Gateway" als "last-resort" auch in Verwendung (?),
konnte ich bei mir noch nicht feststellen (hab' auch noch nicht darauf geachtet, muss ich sagen).

Anbei noch meine /etc/unbound/unbound.conf (ohne Kommentarzeilen):

Code: Alles auswählen

include: "/etc/unbound/unbound.conf.d/*.conf"
do-tcp: no
do-ip6: no
hide-identity: yes
hide-version: yes
remote-control:
	control-enable: no

[Helianthus]

Danke!

OpenDNS hatte ich nur als Beispiel, da ich nicht für 1e10 werben wollte. Aber selbst mit einer Forward-zone von 20 guten Servern wurde kein einziger genutzt.

Der Unterschied liegt im.

Code: Alles auswählen

remote-control:
	control-enable: no

So einen Eintrag hatte ich nicht. Allein wundert es mich, dass offensichtlich yes die Voreinstellung ist. Aber damit haben nun auch die Rootserver erträgliche Antwortzeiten (ca. 500 ms), mit Forwardzone und auskommentiertem Root ca. 60 ms. Root plus Forwardzone bringen wieder ca. 500 ms, (weshalb ich annehme, dass "root.hints" nicht direkt einkompiliert sind, sondern nur als eine Art Notnagel).

Der DNS meines Routers wird anscheinend so auch nicht mehr genutzt. Interessant wäre noch, weshalb er ohne den Fernbedienungsteil angefragt wurde.

Also, vielen Dank für die Hilfe.

[dufty2]

So, hab' nun ein bischen rumgesucht:
Die 'root.hints' sind tatsächlich im unbound-binary einkompiliert:
In den Sourcen finden man sie unter "../iterator/iter_hints.c" und im binary selbst via

Code: Alles auswählen

$ strings /usr/sbin/unbound| grep ROOT-SERVERS.NET

Sie werden auch dann genommen, wenn man ihm eine leere 'root.hints' vorgauckelt, z. B. via

Code: Alles auswählen

# touch /etc/unbound/root.hints

# unbound-checkconf 
[xxx] unbound-checkconf[2642:0] warning: root hints /tmp/root.hints: no NS content
unbound-checkconf: no errors in /etc/unbound/unbound.conf

Scheinbar ist es so (geht aber nicht aus der man-page von 'unbound' bzw. 'unbound.conf' hervor),
dass sobald man die "forward-zone:"-Direktive verwendet, auch der DNS-Server des DHCP verwendet wird.
Da mein Client eine statische IP hat und ergo auch keinen "DHCP Client" hat, benutzt unbound auch bei mir kein Default-Gateway als forwarder.

Warum es jetzt bei Dir klappt mit der "remote-control"-Direktive, ist mir allerdings ein Rätsel,
ich verwende jene lediglich, dass ich keine offene Ports habe (security),
hat aber mit der Server-Auswahl nichts zu tun und wäre für mich eher ein bug.

[Helianthus]

so verhält sich meiner definitiv nicht. Ich nutze unbound 1.4.22-3+deb8u2 armhf mit DietPi und Kernel 3.4.113-sun8i.

Bereits ohne forward-zone fragt er den DNS-Server des DHCP an: (Mit der Forwardzone habe ich ja nur experimentiert, um irgendwo Geschwindigkeit in das System zu bringen.)

Code: Alles auswählen

[] unbound[] info: response for . DNSKEY IN
[] unbound[] info: reply from <.> 192.168.0.1#53

Und seit ich nach dem freetzen meines Routers diesen wiederum beim Pi nachfragen lasse, ging natürlich gar nichts mehr. Es kann sein, dass ich noch nicht alle möglichen Einstellungsvarianten durchprobiert habe, aber ich meine, dass es nur mit folgenden Einstellungen funktioniert :

Code: Alles auswählen

do-not-query-address: 192.168.0.1
do-not-query-localhost: yes
remote-control:
    control-enable: no

So habe ich nun meinen unbound fürs komplette lokale Netz bei normalen Auflösegeschwindigkeiten.

[dufty2]

Mmmh, interessant.
Nö, weiss nicht, woran das liegt.
Wenn ich mein default-gateway als forward-addr einsetze, will mein 1.6.4-1+b1 aus buster (testing) den gar
Sprich, die Auflösung per dig schlägt dann auch fehl:

Code: Alles auswählen

[xxx] unbound[3859:0] info: prime trust anchor
[xxx] unbound[3859:0] info: resolving . DNSKEY IN
[xxx] unbound[3859:0] info: response for . DNSKEY IN
[xxx] unbound[3859:0] info: reply from <.> <default-gateway>#53
[xxx] unbound[3859:0] info: query response was ANSWER
[xxx] unbound[3859:0] info: validate keys with anchor(DS): sec_status_bogus
[xxx] unbound[3859:0] info: failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN
[xxx] unbound[3859:0] info: Could not establish a chain of trust to keys for . DNSKEY IN

Kann man wahrscheinlich anpassen, dass es trotzdem geht.

Evtl. könntest Du mal den 1.6.0-2~bpo8+1 aus den jessie-backports probieren, ob das was an Deinem beobachtbaren Verhalten dann ändert (?)

[Helianthus]

ehrlich gesagt bin ich erstmal froh und dankbar, dass die Software jetzt anscheinend tut was sie soll. Das Interesse nach dem Warum ist zwar vorhanden, aber derzeit eher begrenzt. Einzig werde ich vielleicht noch probieren, was eine root.hints http://www.orsn.org/roothint/root-hint.txt bringt.

Ich frage mich, wie viele sich noch einen eigenen Resolver installieren, der dann aber zunächst doch wieder nur aufs Gateway umleitet. Man sollte Sicherheitsarchitektur öfter mal übers Log kontrollieren.

freundliche Grüße

[wolfn]

In der ct 12/2017 gab es eine schöne Anleitung, die alles und wohl noch mehr abdeckt, was Du Dir wünschst.

Läuft bei mir seit vielen Wochen, inzwischen noch etwas aufgebohrt.