Pihole, unbound Dns over TLS - Test zeigt DoT nicht aktiv?

[ace-drink]

Hi,

ich habe hier PiHole schon lange am laufen mit DNSSEC aber wollte nun auch noch DNS over TLS nutzen.

Daher Unbound auf dem Rapsberry installiert und nutze folgende Config. Es geht alles und wenn ich viatcpdump nachPorts 53 und 853 schaue, sehe ich dasdie Kette wie folgt zu klappen scheint.

Client via Port 53 -> Pihole -> Unbound -> Upstream DNS Server Anfrage via Port 853 -> Antwort an Piholeund von da dann wieder an den lokalen Client.

Warum zeigen mir dann aber Tests wie dieser unter advanced DNS das ich kein TLS nutze?
https://tenta.com/test/?utm_source=blog

oder aber auch hier wenn ich vorherzum testen auf Cloudflare umstelle https://1.1.1.1/help

Habe ich einen Denkfehler? Es geht ja alles und die Anfragen gehen laut TCPDump via 853 Port raus, also sollte es doch als aktive erscheinen?

Würde mich freuen, wenn mir jemand helfen oder mir erklären kann. Interessiert mich einfach.

Alternativ könnte ich auch das Ganze setup kippen und im Router DoT aktivieren und sagen wir Adguard DNS nehmen aber erstens bastel ich gerne und zweitens verliere ich dann die Möglichkeit bestimmte DNS Server zu nutzen die ich bevorzuge und gleichzeitig Custom BLocklists zu haben. Pihole eben.

# Konfiguration für Unbound als DNS für PiHole mit DoT. Basiert auf:
# Konfiguration von https://bartonbytes.com/posts/configure-pi-hole-for-dns-over-tls/
# und Konfiguration von https://docs.pi-hole.net/guides/dns/unbound/

server:
# If no logfile is specified, syslog is used
# chroot: ""
logfile: "/var/log/unbound.log"
verbosity: 0

# If enabled id.server and hostname.bind queries are refused.
hide-identity: yes

# If enabled version.server and version.bind queries are refused.
hide-version: yes

# If yes, Unbound doesn't insert authority/additional sections
# into response messages when those sections are not required.
minimal-responses: yes

# Send minimum amount of information to  upstream servers to
# enhance privacy.
qname-minimisation: yes

# rotates RRSet order in response (the random number
# is taken from the query ID, for speed and thread safety)
rrset-roundrobin: yes

# Enable  or disable whether the upstream queries use TCP only for
# transport.  Useful in tunneling scenarios.
# tcp-upstream: yes

# Enable or disable whether the upstream queries use SSL only for
# transport.
ssl-upstream: yes

# certificates used for authenticating connections made to outside peers
ssl-cert-bundle: /etc/ssl/certs/ca-certificates.crt

# Interface to use to connect to the network
interface: 127.0.0.1

# Port for Usage in Pi-Hole as 127.0.0.1#5533
port: 5533

# Enable or disable whether TCP/UDP/IP4 queries are answered or issued.
do-ip4: yes
do-udp: yes
do-tcp: yes

# May be set to yes if you have IPv6 connectivity
do-ip6: no

# prefer IPv6 over IPv4 yes or no
prefer-ip6: no

# Trust glue only if it is within the servers authority
harden-glue: yes

# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes

# Don’t use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no

# Reduce EDNS reassembly buffer size.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472

# TTL bounds for cache
cache-min-ttl: 600
cache-max-ttl: 14400

# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes

# One thread should be sufficient, can be increased on beefy machines
num-threads: 1

# Cache Memory rrset should have double size as msg
msg-cache-size: 50m
rrset-cache-size: 100m

# Accelerate UDP with multithreading
so-reuseport: yes

# Ensure kernel buffer is large enough to not loose messages in traffic spikes
so-rcvbuf: 1m

# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
# private-address: 169.254.0.0/16
# private-address: 172.16.0.0/12
# private-address: 10.0.0.0/8
# private-address: fd00::/8
# private-address: fe80::/10

access-control: 127.0.0.0/8 allow

forward-zone:
# forward all queries to these DNS servers:
name: "."
forward-addr: 185.95.218.42@853#dns.digitale-gesellschaft.ch
forward-addr: 94.140.15.140@853#dns-unfiltered.adguard.com

 

[0x7c9aa894]

$ man unbound.conf

tls-upstream: <yes or no>
              Enabled or disable whether the upstream queries use TLS only  for  transport.
              Default is no.  Useful in tunneling scenarios.  The TLS contains plain DNS in
              TCP wireformat.  The other server must support  this  (see  tls-service-key).
              If  you  enable this, also configure a tls-cert-bundle or use tls-win-cert to
              load CA certs, otherwise the connections cannot be authenticated.   This  op‐
              tion  enables TLS for all of them, but if you do not set this you can config‐
              ure TLS specifically for some forward zones with  forward-tls-upstream.   And
              also with stub-tls-upstream.

forward-tls-upstream: <yes or no>
              Enabled or disable whether the queries to this forwarder use TLS  for  trans‐
              port.   Default  is no.  If you enable this, also configure a tls-cert-bundle
              or use tls-win-cert to load CA certs, otherwise the connections cannot be au‐
              thenticated.

Ergänzung (29. November 2021)

Also beide Optionen sind default "no"

Du mußt also tls-upstream: yes setzten und die Forward zone anpassen:

forward-zone:
     name: "."
forward-tls-upstream: yes
     forward-addr: 185.95.218.42@853#dns.digitale-gesellschaft.ch
     forward-addr: 94.140.15.140@853#dns-unfiltered.adguard.com

Ergänzung (29. November 2021)

Außerdem erhöhe die Verbosity und schaue was im log-file steht ...

 

[Darkman.X]

Ich frage mich gerade, wie eine Internetseite herausfinden kann wie ich mit meinem DNS-Server kommuniziere, ob ich nun unverschlüsselt oder ob ich DoH/DoT nutze?

Das kann ein so ein Test meiner Meinung nach nicht erkennen, weil DNS-Server untereinander vermutlich mit anderen Protokollen / Ports kommunizieren. Solche Tests können nur herausfinden, welchen DNS-Server man nutzt.
Bei mir zeigte der Test z.B. TLS Enabled = False an, obwohl ich das DoT der Fritzbox nutze. Oder das DoT der Fritzbox ist kaputt 🤷🏻‍♂️

 

[ace-drink]

Hi! @0x7c9aa894

Ich habe ja ssl-upstream schon drin, was synonym für tls-upstream genutzt werden kann und für alle Verbidungen gilt. Daher muss man forward-tls-upstream: yes nixht extra setzen.

Wie gesagt, es geht ja alles und TCPdump und Wireshark bestätigen ja die verschlküsstelten TLS1.3 Verbindungen. Nur Tests spucken es so nicht zurück.

Inwzischen weiss ich das die Tests, wohl Probleme haben das zu erkennen, wenn in meiner DNS Kette noch lokal unverschlüsslelte Anfragen sind. Also vom Client zu Pihole (was ja rein intern passiert)

Letztlich alles gut. Systemprotokolle und Sniffer tools bestätigen das alles upstream verschlüsselt ist.

Danke dennoch für den Hilfsversuch.

@Darkman.X
Na ja, DoT läuft eben über den Standard TLS Port 853. Das ist fakt. Normaler DNS traffic, unverschlüsselt über Port 53. Das ist ebenfalls fakt. Danach halten die halt Ausschau aber je nach Szenario, siehe bei mir, haben dir durchaus Probleme es korrekt zu erkennen.
Wenn du auf Nummer sicher gehen willst musst du deinen Netzwerkverkehr mitschneiden und schauen, ob wirklich die von dir gewünschten DNS Server via Port 853 angefragt werden.

 

[Darkman.X]

Na ja, DoT läuft eben über den Standard TLS Port 853. Das ist fakt. Normaler DNS traffic, unverschlüsselt über Port 53. Das ist ebenfalls fakt. Danach halten die halt Ausschau aber je nach Szenario, siehe bei mir, haben dir durchaus Probleme es korrekt zu erkennen.
Wenn du auf Nummer sicher gehen willst musst du deinen Netzwerkverkehr mitschneiden und schauen, ob wirklich die von dir gewünschten DNS Server via Port 853 angefragt werden.

Deine Fakten sind ja auch richtig, aber das ist halt deine Kommunikation mit dem DNS-Server, das kann eine außenstehende Internetseite wie deine verlinkte Testseite nicht sehen. Wie denn auch? Deshalb ist der Test auch blödsinnig.
Zumindest kann ich auf der Seite nicht herauslesen, wie es die Bewertung durchführt. Führt es selber eine TLS-Verbindung mit dem DNS-Server durch, oder wie kommen sie zu der TRUE/FALSE-Einschätzung?

Du hast es bereits geprüft und siehst Traffic auf dem Port 853. Dann lass es dabei und vertraue nicht länger auf so einer fehleranfälligen Seite.

EDIT:
Das kam vielleicht bei meinem 1. Text nicht so klar rüber. Das "Ich frage mich..." war eher rhetorisch gemeint, weil eine Testseite das nicht bewerten kann.

 

[xman00]

Webseiten wie browserleaks.com/dns oder die genannte 1.1.1.1 Testseite können sehr wohl herausfinden, ob und wie du deren DNS Server nutzt. Dazu erzeugen sie neue zufällige und kurzlebige A oder CNAME records in deren Zone für die sie autoritativ sind. Wenn dann der record bei deren autoritativen DNS Server abgefragt wird, schaut man einfach auf die Herkunft des anfragenden DNS Servers. Ist es deren eigener DNS welcher z.B. DoT für public serviert, können sie das auch logischerweise auf so einer "Testseite" anzeigen.

Ergänzung (29. November 2021)

Der Test (die Spalte "TLS enabled") von dieser seltsamen Seite (tenta.com) bezieht sich wohl eher darauf anzuzeigen, ob der anfragenden rekursive DNS Server den Query an ihren autoritativen DNS Server verschlüsselt via TLS gestellt hat. An der Stelle hat das also nichts damit zu tun, ob dein Client DoT o.ä. nutzt.

 

[Darkman.X]

Wurde irgendwo behauptet, dass man mit solchen Tests nicht herausfinden kann, welchen DNS-Server man nutzt? Also ich hatte es nicht behauptet:

Solche Tests können nur herausfinden, welchen DNS-Server man nutzt.

Aber Danke für deine Bestätigung:

Der Test (die Spalte "TLS enabled") von dieser seltsamen Seite (tenta.com) bezieht sich wohl eher darauf anzuzeigen, ob der anfragenden rekursive DNS Server den Query an ihren autoritativen DNS Server verschlüsselt via TLS gestellt hat. An der Stelle hat das also nichts damit zu tun, ob dein Client DoT o.ä. nutzt.

 

[xman00]

https://1.1.1.1/help zeigt an, ob man deren DoT oder DoH Server nutzt. Es sei denn, du hast in den Browsereinstellungen in Firefox z.B. einen anderen DNS Server hinterlegt.

Egal ob ich bei mir DoT oder DoH von Cloudflare nutze. Deren Seite zeigt immer richtig an, was ich nutze. Wenn das beim Themenersteller nicht funktioniert, stimmt etwas nicht. Natürlich vorausgesetzt, dass auch Cloudflare als upstream genutzt wird