Würde ich primär nicht machen, denn wenn dann Pi-hole nicht geht, verbaust du dir evtl. den Weg über pihole -r - für die Reparatur brauchst du eine funktionierende DNS Auflösung.
Läuft wieder.
Ich erstelle nun in /etc/dnsmasq.d/ eine neue Datei mit dem namen subnetze.conf
In dieser Datei steht:
rev-server=192.160.1.0/24,192.168.1.1
rev-server=192.160.10.0/24,192.168.10.1
rev-server=192.160.20.0/24,192.168.20.1 (in dem Netz steht nur der Pi-hole)
rev-server=192.160.30.0/24,192.168.30.1
rev-server=192.160.40.0/24,192.168.40.1
rev-server=192.160.50.0/24,192.168.50.1
rev-server=192.160.60.0/24,192.168.60.1
rev-server=192.160.178.0/24,192.168.178.1
Muss ich jetzt Conditional Forwarding noch aktivieren oder nicht und was muss dann dort stehen?
Nein, dass hast du mit deinen manuellen Einträgen getan. Nach den Änderungen musst du Pi-hole lediglich einmal neu starten.
Habe ich nun alles so wie beschrieben gemacht aber es geht nicht, da ich weiterhin nur IP Adresse angezeigt bekomme.
Habe nun weiter gewartet aber es funktioniert nicht.
Entweder ist der Inhalt der Datei falsch oder diese Datei wird vom Pi-hole nicht gesehen bzw. genutzt.
Sorry, ich war ein paar Tage ordentlich eingespannt. Gibt mal ein konkretes Beispiel, für welche Addresse brauchst du einen Hostnamen und welcher wäre das?
Was ist denn der Output von
dig -x IP (wobei IP die IP eines Clients ist, von dem du keinen Hostnamen sieht).
Was steht denn zeitgleich mit dieser Anfrage in /var/log/pihole.log
Hallo anbei die Daten:
Hier sollte mein QNAP aufgelöst werden.
pi@rpi-pihole:~ $ dig -x 192.168.50.210
; <<>> DiG 9.16.22-Raspbian <<>> -x 192.168.50.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62886
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;210.50.168.192.in-addr.arpa. IN PTR
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 08 17:28:17 CET 2022
;; MSG SIZE rcvd: 56
Feb 8 17:28:17 dnsmasq[884]: query[PTR] 210.50.168.192.in-addr.arpa from 127.0.0.1
Feb 8 17:28:17 dnsmasq[884]: config 192.168.50.210 is NXDOMAIN
Feb 8 17:28:17 dnsmasq[884]: validation result is INSECURE
Ok, und nun fragen das Ziel mal direkt an
dig -x 192.168.50.210 @192.168.50.1
pi@rpi-pihole:~ $ dig -x 192.168.50.210 @192.168.50.1
; <<>> DiG 9.16.22-Raspbian <<>> -x 192.168.50.210 @192.168.50.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37395
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;210.50.168.192.in-addr.arpa. IN PTR
;; Query time: 0 msec
;; SERVER: 192.168.50.1#53(192.168.50.1)
;; WHEN: Wed Feb 09 20:38:44 CET 2022
;; MSG SIZE rcvd: 56
Die Ausgabe zeigt, dass das Ziel 192.168.50.1 den Hostnamen auch nicht kennt. Um welches Gerät handelt es sich dabei? Bist du sicher, dass das den Hostnamen deines QNAP kennen sollte?
Die 192.168.50.1 ist mein Gateway. Der Router/GW ist eine Unifi Dream Machine Pro.
Die Namen werden ja angezeigt wenn ich unter Use Conditional Forwarding die 192.168.0.0/16.
Es geht nur nicht mit der Datei und den einzelnen Subnetzen.
Habe es mal mit der IP von meinem Mac probiert und da wird der Name angezeigt
pi@rpi-pihole:~ $ dig -x 192.168.50.21 @192.168.50.1
; <<>> DiG 9.16.22-Raspbian <<>> -x 192.168.50.21 @192.168.50.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57717
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;21.50.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
21.50.168.192.in-addr.arpa. 0 IN PTR Thorstens-Mini.
;; Query time: 0 msec
;; SERVER: 192.168.50.1#53(192.168.50.1)
;; WHEN: Thu Feb 10 08:49:56 CET 2022
;; MSG SIZE rcvd: 83
So sieht es dann im Pi-hole aus.
Und wenn du nochmal nur dig -x 192.168.50.21 ausführst, ohne Ziel DNS server?
Dann kommt das:
pi@rpi-pihole:~ $ dig -x 192.168.50.21
; <<>> DiG 9.16.22-Raspbian <<>> -x 192.168.50.21
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65523
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;21.50.168.192.in-addr.arpa. IN PTR
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb 10 22:06:23 CET 2022
;; MSG SIZE rcvd: 55
Es scheint tatsächlich an der Pi-hole Konfiguration zu liegen.
Was gibt denn
cat /var/log/pihole.log | grep "using nameserver"
cat /etc/dnsmasq.d/01-pihole.conf
aus?
Dann kommt das:
pi@rpi-pihole:~ $ cat /var/log/pihole.log | grep "using nameserver"
pi@rpi-pihole:~ $ cat /etc/dnsmasq.d/01-pihole.conf
# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
#
# Dnsmasq config for Pi-hole's FTLDNS
#
# This file is copyright under the latest version of the EUPL.
# Please see LICENSE file for your rights under this license.
###############################################################################
# FILE AUTOMATICALLY POPULATED BY PI-HOLE INSTALL/UPDATE PROCEDURE. #
# ANY CHANGES MADE TO THIS FILE AFTER INSTALL WILL BE LOST ON THE NEXT UPDATE #
# #
# IF YOU WISH TO CHANGE THE UPSTREAM SERVERS, CHANGE THEM IN: #
# /etc/pihole/setupVars.conf #
# #
# ANY OTHER CHANGES SHOULD BE MADE IN A SEPARATE CONFIG FILE #
# WITHIN /etc/dnsmasq.d/yourname.conf #
###############################################################################
addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list
localise-queries
no-resolv
cache-size=10000
log-queries
log-facility=/var/log/pihole.log
log-async
server=127.0.0.1#5335
domain-needed
expand-hosts
bogus-priv
dnssec
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
interface=eth0
Du hast sehr wahrscheinlich Never forward reverse lookups for private IP ranges angehakt.
Damit würden dann Rückwärtsanfragen für private IP-Adressen (wie dig -x 192.168.50.21) nicht mehr weitergeleitet.
Pi-holes Weboberfläche sagt dazu explizit:
Important : Enabling these two options may increase your privacy, but may also prevent you from being able to access local hostnames if the Pi-hole is not used as DHCP server.
Aber um nochmal Deine Ausgangsfrage aufzugreifen:
Wenn das funktioniert, würde ich diese einfachere Konfigurationsvariante bevorzugen.
Der Hinweise für Never forward reverse lookups for private IP ranges ist grundsätzlich auch in dieser Variante zu beachten.
Vielleicht war es einfach nur das, was Deine ursprünglich funktionierende /16er-Konfiguration aus dem Tritt gebracht hat?
Hallo und ja richtig war aktiviert und habe ich nun abgeschaltet und hat keine Auswirkungen.
Kann man den prüfen, ob diese Datei überhaupt genutzt wird?
Du startet Pi-hole neu mit pihole restartdns und schaust in /var/log/pihole.log nach:
cat /var/log/pihole.log | grep "using nameserver"
Feb 11 21:13:31 dnsmasq[11467]: using nameserver 127.0.0.1#5335
Feb 11 21:13:31 dnsmasq[11467]: using nameserver 10.0.1.1#53 for domain 1.0.10.in-addr.arpa
Sieht dann so aus:
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 127.0.0.1#5335
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 192.168.1.1#53 for domain 1.160.192.in-addr.arpa (no DNSSEC)
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 192.168.10.1#53 for domain 10.160.192.in-addr.arpa (no DNSSEC)
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 192.168.20.1#53 for domain 20.160.192.in-addr.arpa (no DNSSEC)
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 192.168.30.1#53 for domain 30.160.192.in-addr.arpa (no DNSSEC)
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 192.168.40.1#53 for domain 40.160.192.in-addr.arpa (no DNSSEC)
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 192.168.50.1#53 for domain 50.160.192.in-addr.arpa (no DNSSEC)
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 192.168.60.1#53 for domain 60.160.192.in-addr.arpa (no DNSSEC)
Feb 13 20:30:27 dnsmasq[12174]: using nameserver 192.168.178.1#53 for domain 178.160.192.in-addr.arpa (no DNSSEC)
Feb 13 20:30:27 dnsmasq[12174]: using only locally-known addresses for onion
Feb 13 20:30:27 dnsmasq[12174]: using only locally-known addresses for bind
Feb 13 20:30:27 dnsmasq[12174]: using only locally-known addresses for invalid
Feb 13 20:30:27 dnsmasq[12174]: using only locally-known addresses for localhost
Feb 13 20:30:27 dnsmasq[12174]: using only locally-known addresses for test
Das sieht eigentlich gut aus, es sollte also funktionieren. Bitte lade mal einen neuen Debug Token hoch.