Kein DNS

[maclovlin]

Hallo in die Runde,

folgendes Problem, an dem ich mir schon seit Tagen die Zähne ausbeisse.

Opnsense, frisch auf einer Sophos SG-105 installiert, v23.7.9.

Richtige Schnittstellen zugewiesen.

Am WAN hängt eine Fritzbox, als reines, dummes Modem. Die OPNsense macht die Einwahl über PPPoe.
Am LAN, logischweise mein internes Netzwerk.

Bei der Einrichtung, im Wizard, habe ich folgendes eingestellt:
- keine DNS Server eingetragen
- "Allow DNS server list to be overridden by DHCP/PPP on WAN" -> haken raus
- der Rest ist default geblieben

Die PPPoe Einwahl gelingt, nur funktioniert die DNS Auflösung weder auf der OPNSense noch im LAN,
erst wenn ich unter "Services: Unbound DNS: Query Forwarding" einen fremden DNS Server hinzufüge, funktioniert alles.

Das kann einfach nicht richtig sein, da ich nur den Unbound als resolver benutzen möchte.

Was übersehe ich?

[Patrick M. Hausen]

Nix  ;)

Wirf dig/drill und tcpdump an und guck, was genau passiert.

[knebb]

- keine DNS Server eingetragen
- "Allow DNS server list to be overridden by DHCP/PPP on WAN" -> haken raus

Ich glaube, ihr habt da beide etwas übersehen. :D

Also: Du trägst keine DNS-Server ein UND verbietest, dass die (leere) Liste durch die PPPoE-Einstellungen überschrieben wird. as ist ads Ergebnis? Richtig, keine DNS Server.

Und wenn Du jetzt Unbound verwenden willst, geht das nicht? Woher soll der Unbound denn wissen, welche DNS er befragen soll?


Ja, ein bind kann aus einer mitgegebenen root-NS von oben herab anfangen aufzulösen. Das macht aber nur im Ausnahmefall Sinn und deshalb kann der Unbound das wohl nicht. Steht so auch in dessen Doku: "Unbound does not perform recursion itself ".  Er muss also alle Anfragen "forwarden".

Nur: wohin soll er die weiterleiten, wenn ihm keinerlei DNS-Server bekannt sind?

Ich zitiere mal aus der Hilfestellung bei den Einstellungen (Unbound -> Query Forwarding":

Code Select Expand

If "Use System Nameservers" is checked, Unbound will use the DNS servers entered in System->Settings->General or those obtained via DHCP or PPP on WAN if the "Allow DNS server list to be overridden by DHCP/PPP on WAN" is checked.
Ich finde, das erklärt alles, oder?

Also:
Mache den Haken bei "Allow DNS server list to be overwritten" und dann sollte es einwandfrei funktionieren.

/KNEBB

[Patrick M. Hausen]

Ich glaube, ihr habt da beide etwas übersehen. :D

Schon möglich.  :)

Und wenn Du jetzt Unbound verwenden willst, geht das nicht? Woher soll der Unbound denn wissen, welche DNS er befragen soll?

Ich bin davon ausgegangen, der kann das rekursiv wie ein vernünftiger Resolver das eben so tut. Ich verwende allerdings überall BIND und habe mir nicht die Mühe gemacht, das zu verifizieren.

Steht so auch in dessen Doku: "Unbound does not perform recursion itself ".  Er muss also alle Anfragen "forwarden".

Das ist nicht ganz richtig. "Unbound does not perform recursion itself for the forward zone". For the forward zone, nicht generell.

https://unbound.docs.nlnetlabs.nl/en/latest/use-cases/home-resolver.html
"Unbound is a powerful validating, recursive, caching DNS resolver."

Ich würde mir mal die generierte unbound.conf ansehen und eben mit tcpdump und manuellen Lookups angucken, was passiert.

[knebb]

Stimmt, da war ich nicht ganz richtig. Grundsätzlich scheint der das zu können. Es existiert audf der OPNSense sogar eine "root.hints".

Nur ignoriert er die offenbar unter OPNSense. Schaue ich in die /var/unbound/unbound.conf, finde ich dort:

Code Select Expand


forward-zone:
    name: "."
        forward-addr: 1.1.1.1
        forward-addr: 8.8.8.8
        forward-addr: 185.90.156.222
        forward-addr: 185.90.157.222
        forward-addr: 217.237.151.51
        forward-addr: 89.233.43.71


Gibt es diese "." forward Zone bei Dir, @maclovlin? Und ist vermutlich leer?

Das sind bei mir genau die konfigurierten DNS. Der Unbound scheint (was meine Vermutung war) in OPNSense keine "top-to-bottom" Auflösung zu machen.

/KNEBB

[Patrick M. Hausen]

Das ist aber ein Bug - ich mach mal einen Pull-Request ...

Der ganze forward-zone "." Abschnitte gehört weg, wenn die Liste leer ist.

EDIT: kein Bug - ich glaube nicht, dass es möglich ist, hier zu einer leeren Liste zu kommen. Wenn man keine Forwarder - entweder global oder für einzelne Domains - angelegt hat, wird der Abschnitt auch nicht generiert. Ist alles gekapselt in:

Code Select Expand

{%   if all_forwards|length > 0 %}
[...]
{%   endif %}

Aber ohne Beteiligung des Thread-Erstellers werden wir nicht herausfinden, was denn nun in dieser speziellen Situation klemmt.

[maclovlin]

Abend,

hier die unbound.conf, keine Forward einträge drin, das ist interessant, da ich gerade jetzt ein Forward drin habe, auf die 1.1.1.1:

Code Select Expand


# cat /var/unbound/unbound.conf
##########################
# Unbound Configuration
##########################

##
# Server configuration
##
server:
chroot: /var/unbound
username: unbound
directory: /var/unbound
pidfile: /var/run/unbound.pid
root-hints: /var/unbound/root.hints
use-syslog: yes
port: 53
include: /var/unbound/advanced.conf
harden-referral-path: no
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
so-reuseport: yes
module-config: "python validator iterator"
num-threads: 2
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
auto-trust-anchor-file: /var/unbound/root.key



# Interface IP(s) to bind to
interface: 0.0.0.0
interface: ::
interface-automatic: yes

# Outgoing interfaces to be used
outgoing-interface: 37.138.***.***


# Private networks for DNS Rebinding prevention (when enabled)
private-address: 0.0.0.0/8
private-address: 10.0.0.0/8
private-address: 100.64.0.0/10
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 192.0.2.0/24
private-address: 192.168.0.0/16
private-address: 198.18.0.0/15
private-address: 198.51.100.0/24
private-address: 203.0.113.0/24
private-address: 233.252.0.0/24
private-address: ::1/128
private-address: 2001:db8::/32
private-address: fc00::/8
private-address: fd00::/8
private-address: fe80::/10


# Private domains (DNS Rebinding)
include: /var/unbound/private_domains.conf

# Static host entries
include: /var/unbound/host_entries.conf

# DHCP leases (if configured)
include: /var/unbound/dhcpleases.conf

# Custom includes
include: /var/unbound/etc/*.conf



python:
python-script: dnsbl_module.py

remote-control:
    control-enable: yes
    control-interface: 127.0.0.1
    control-port: 953
    server-key-file: /var/unbound/unbound_server.key
    server-cert-file: /var/unbound/unbound_server.pem
    control-key-file: /var/unbound/unbound_control.key
    control-cert-file: /var/unbound/unbound_control.pem


Das "Outgoing Network Interfaces" habe ich auf "WAN" eingestellt und das ist auch meine öffentliche IP.

Die Einstellungen speichere ich mit "Apply" und dann gehe ich auf das kringel oben um den Unbound neu zu starten. Das nur so am Rande.

[maclovlin]

Hier die Ergebnisse von drill:

Code Select Expand


# drill freenet.de
Error: error sending query: Could not send or receive, because of network error

# drill freenet.de @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 19708
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; freenet.de.  IN      A

;; ANSWER SECTION:
freenet.de.     1       IN      A       62.104.23.121

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 26 msec
;; SERVER: 8.8.8.8
;; WHEN: Thu Dec  7 18:59:32 2023
;; MSG SIZE  rcvd: 44

# drill google.de
Error: error sending query: Could not send or receive, because of network error

# drill google.de @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 46255
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; google.de.   IN      A

;; ANSWER SECTION:
google.de.      300     IN      A       142.250.186.131

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 33 msec
;; SERVER: 8.8.8.8
;; WHEN: Thu Dec  7 19:00:09 2023
;; MSG SIZE  rcvd: 43


PS: Den Forwarder habe ich für die Tests deaktiviert.

[maclovlin]

Das spuckt tcpdump aus, auf dem LAN interface, Forwarder aus:

Code Select Expand


19:44:30.341822 IP (tos 0x0, ttl 128, id 60380, offset 0, flags [none], proto UDP (17), length 65)
    192.168.178.5.62578 > OPNsense.domain: [udp sum ok] 56360+ A? www.supermagnete.de. (37)
19:44:30.345418 IP (tos 0x0, ttl 64, id 7617, offset 0, flags [none], proto UDP (17), length 65)
    OPNsense.domain > 192.168.178.5.62578: [udp sum ok] 56360 ServFail q: A? www.supermagnete.de. 0/0/0 (37)


Auf dem WAN Interface ist totenstille.

Mein tcpdump aufruf: tcpdump -vv -i igb0 port 53

[knebb]

Naja, dass auf dem ROT Stille ist, ist ja klar. Der Umbound weiß ja nicht, wo er nachfragen soll. Auch wenn er das möglicherweise wissen müsste.

Andere Frage: Gibt es einen speziellen Grund, warum Du keinen Forwarder benutzen willst? Eigentlich macht das ja nicht unbedingt Sinn, wenn Deine Kiste alles selbst auflöst....

/KNEBB

[Patrick M. Hausen]

Andere Frage: Gibt es einen speziellen Grund, warum Du keinen Forwarder benutzen willst? Eigentlich macht das ja nicht unbedingt Sinn, wenn Deine Kiste alles selbst auflöst....

Das ist die datensparsamste Version, DNS zu machen, und das, was ich grundsätzlich jedem empfehle.

[maclovlin]

Eigentlich gibts nur einen Grund, Sicherheit und Anonymität ( so gut wie geht ).

Die Unbound Anfragen gehen ja direkt an die Root Server.

Der Denkanstoss kam von hier:
https://www.kuketz-blog.de/pi-hole-einrichtung-und-konfiguration-mit-unbound-adblocker-teil2/

Habt Ihr was "verdächtiges" in der unbound.conf entdecken können?

[Patrick M. Hausen]

Lass das outgoing interface mal weg, setz den Haken bei

System > Settings > General > Do not use the local DNS service as a nameserver for this system

wieder rein, und schreib in den ersten Nameserver explizit 127.0.0.1

Dann teste mal mit drill auf der Sense. Wenn es dann immer noch ein servfail zurück gibt, dann müssen wir wohl mal die Unbound-Logfiles angucken.

[maclovlin]

Gemacht, kein Erfolg.

Kommt sofort survfail

Code Select Expand


# drill freenet.de
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 26644
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; freenet.de.  IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 3 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Dec  7 20:23:02 2023
;; MSG SIZE  rcvd: 28


[knebb]

Eigentlich gibts nur einen Grund, Sicherheit und Anonymität ( so gut wie geht ).

Die Unbound Anfragen gehen ja direkt an die Root Server.

Der Denkanstoss kam von hier:
https://www.kuketz-blog.de/pi-hole-einrichtung-und-konfiguration-mit-unbound-adblocker-teil2/

Habt Ihr was "verdächtiges" in der unbound.conf entdecken können?

Naja, da werden ja auch vertrauenswürdige Server genannt.
Und wer garantiert, dass die Root-Server nicht aufzeichnen?
Hast Du eigentlich eine feste IP? Oder eine dynamische? Dann ist der Wiedererkennungseffekt bei öffentlichen DNS-Servern ja eh' gering....
Und wenn Du genug Forward-Server von.verschiedenen Anbietern einträgst, ist sowieso kein Profiling möglich.

Ich finde, das ist mit Kanonen auf Spatzen geschossen.
Aber gut, entscheidet natürlich jeder selbst.

Grüße
/KNEBB