[Pi-Hole] Ervaringen & discussie

[Koepert]

mrdemc schreef op vrijdag 31 december 2021 @ 23:07:
[...]


Zoals in dit topic ook naar voren komt:
https://discourse.pi-hole...-192-in-addr-arpa/18241/4

Heb je hoogstwaarschijnlijk een DNS loop. As je terugzoekt in dit topic is dat meerdere keren benoemd hoe je dat kan oplossen, waaronder hier: mrdemc in "[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4"

Figured as much

Heb conditional forwarding nu ff uitgezet. Nu had jij t in dat topic wat je linkt over wan en lan dns. Ik heb n Fritzbox 4040.. ik ben in de veronderstelling dat ik t ‘goed’ gedaan heb.. ik kan bij ipv settings de dns ingeven (network > network settings > ipv4 settings.. die staat op de ip van de pihole vm (zonder Port # vm heeft unbound en pihole)

En bij Internet > Account Information > DNS server. Die staat op ‘ laat provider dit doen’

Dus waar gaat t dan mis? Beide ‘never’ vinkjes bij pihole dns staan aan.

Voor de volledigheid. Mijn router is IP.1. die heeft dus zoals hierboven de DNS op .38 staan. Geen Port#. Op .38 zit een Proxmox VM met pihole & Unbound voor DNS (dus Port# 53 en 5335). Waar moet ik dan welk IP invoeren om mn DNS, recursive, zonder loop, met bij voorkeur duidelijke client-herkenning, te krijgen?
En is local DNS in Pihole dan zo simpel als "NAS" = IP .5000 NAS? (dus zonder enig domein .com/.tk/etc

[ Voor 16% gewijzigd door Koepert op 01-01-2022 00:21 . Reden: Volledigheid ]

[Memphisto]

nero355 schreef op vrijdag 31 december 2021 @ 15:46:
[...]

Tja, haal ze één voor één weg en doe daarna een Gravity Update en kijk of het op een bepaald moment wel goed gaat

Ik zou in ieder geval daarmee beginnen!

Dat hielp inderdaad. Wel apart/jammer dat de foutmelding niet wat meer richting gaf.
Als je op de foutmelding zoekt, volgen er toch heel wat meer ingrijpendere oplossingsrichtingen.

[nero355]

deHakkelaar schreef op vrijdag 31 december 2021 @ 17:33:
Die viel me geeneens op

Waarom niet gewoon dat tweede en/of derde DHCP DNS IP veldje configureren met een ongebruikt IP welke nog wel binnen het subnet valt maar buiten de DHCP scope?

Mogelijk zelfs beter als de router toelaat, configureren met private IP's die buiten het toegepaste subnet vallen waarnaartoe een route onmogelijk is.
Voor de client maakt het toch geen drol uit ofdat die extra DNS IP's niet reageren.
Zolang die ééne maar antwoord.

Dat is dus niet waar!

Ik heb ooit de gevolgen van :
- DNS Server 1 = UP
- DNS Server 2 = DOWN
meegemaakt en dat gaf echt een hele nare ervaring met haperingen en time-outs!

Kortom : Dat wil ik echt nooit meer meemaken!

Een Pi-hole host met twee interfaces en IP's, waarvan de één afhankelijk is van de UP status van de ander, blijft nog steeds een single point of failure.
Dus bespaar de moeite/complexiteit zou ik zeggen toch?

Dat boeit dan ook helemaal niet : Het gaat erom dat je de Router blij houdt, want die accepteert soms niet meerdere keren hetzelfde IP dus geef je hem een IP dat eigenlijk hetzelfde doet, maar dat weet die domme Router niet!

Memphisto schreef op zaterdag 1 januari 2022 @ 10:19:
Dat hielp inderdaad. Wel apart/jammer dat de foutmelding niet wat meer richting gaf.
Als je op de foutmelding zoekt, volgen er toch heel wat meer ingrijpendere oplossingsrichtingen.

Ik zou zeggen submit een bug/feature request @ http://discourse.pi-hole.net want ik geef je 100% gelijk daarin!

Geef ik het wel een daarna!

Koepert schreef op vrijdag 31 december 2021 @ 23:34:
Heb conditional forwarding nu ff uitgezet. Nu had jij t in dat topic wat je linkt over wan en lan dns. Ik heb n Fritzbox 4040.. ik ben in de veronderstelling dat ik t ‘goed’ gedaan heb.. ik kan bij ipv settings de dns ingeven (network > network settings > ipv4 settings.. die staat op de ip van de pihole vm (zonder Port # vm heeft unbound en pihole)

En bij Internet > Account Information > DNS server. Die staat op ‘ laat provider dit doen’

Dus waar gaat t dan mis? Beide ‘never’ vinkjes bij pihole dns staan aan.

Voor de volledigheid. Mijn router is IP.1. die heeft dus zoals hierboven de DNS op .38 staan. Geen Port#. Op .38 zit een Proxmox VM met pihole & Unbound voor DNS (dus Port# 53 en 5335). Waar moet ik dan welk IP invoeren om mn DNS, recursive, zonder loop, met bij voorkeur duidelijke client-herkenning, te krijgen?

Alles wat je hebt gedaan klinkt opzich wel goed dus laat effe weten of het probleem nu zonder Conditional Forwarding is opgelost ?!

En is local DNS in Pihole dan zo simpel als "NAS" = IP .5000 NAS? (dus zonder enig domein .com/.tk/etc

Er is tegenwoordig een hele simpele webGUI optie die prima werkt voor dat soort dingen : Local DNS Records

Zo heb ik bijvoorbeeld de volgende "domeinen" :
- thuis.lan voor het normale netwerk
- management.thuis.lan voor mijn apparatuur in mijn Management VLAN

Dus ik zou zeggen verzin ook iets dergelijks voor je netwerk en laat Conditional Forwarding lekker voor wat het is...

[deHakkelaar]

@Koepert :

https://docs.pi-hole.net/routers/fritzbox/

[deHakkelaar]

nero355 schreef op zaterdag 1 januari 2022 @ 16:55:
[...]
Ik heb ooit de gevolgen van :
- DNS Server 1 = UP
- DNS Server 2 = DOWN
meegemaakt en dat gaf echt een hele nare ervaring met haperingen en time-outs!

Kortom : Dat wil ik echt nooit meer meemaken!

Hmm ik had onlangs m'n tweede Pi-hole node down gebracht, voor ongeveer een uurtje of twee, omdat ik het zeer grote 32GB SD kaartje wou overzetten naar een klein 8GB kaartje om zodoende de grote voor wat anders in te kunnen zetten.
Ik merkte niet echt iets substantieels.
Zal volgende keer beter opletten

[nero355]

deHakkelaar schreef op zaterdag 1 januari 2022 @ 17:08:
Hmm ik had onlangs m'n tweede Pi-hole node down gebracht, voor ongeveer een uurtje of twee, omdat ik het zeer grote 32GB SD kaartje wou overzetten naar een klein 8GB kaartje om zodoende de grote voor wat anders in te kunnen zetten.
Ik merkte niet echt iets substantieels.
Zal volgende keer beter opletten

Het kan uiteraard een verschil in het gebruikte OS en browser zijn (destijds vs. nu en zo...) maar we weten alweer een tijdje dat als je twee Pi-Hole instances draait dat #2 ook een aardig gedeelte van de queries moet verwerken dus ze worden gewoon beiden gebruikt en de kans op time-outs is dus nog steeds aanwezig!

[deHakkelaar]

@Eraser127 , als je @nero355 's advies wilt uitvoeren voor Bullseye, hieronder hoe je een boel IP's aan je Pi kan toevoegen (stukje naar beneden scrollen naar dhcpcd-hooks):
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[deHakkelaar]

@nero355 , hangt idd totaal af van de OS implementatie.
Windows doet bv zoiets als onderstaande:
https://www.ghacks.net/20...me-resolution-in-windows/

[deHakkelaar]

@nero355 , onderstaand hoe pihole-FTL omgaat met meerder upstream DNS servers:
https://docs.pi-hole.net/...-best-forward-destination

[ Voor 3% gewijzigd door deHakkelaar op 01-01-2022 17:40 ]

[Koepert]

deHakkelaar schreef op zaterdag 1 januari 2022 @ 17:06:
@Koepert :

https://docs.pi-hole.net/routers/fritzbox/

Ja ik heb dus methode 1 (Distribute Pi-hole as DNS server via DHCP) in gebruik (met daarnaast unbound als dns upstream voor de pihole) en had conditional forwarding aan. Nu uit en lijkt goed te gaan. Maar nu dus niet de clients op naam, maar dat kan dan evt met Local DNS begrijp ik. Of zou methode 2 een betere optie zijn? Dus Pi-hole as upstream DNS server for your Fritz!Box ?

[deHakkelaar]

@Koepert , als je exact de router en Pi-hole hebt geconfigureerd volgens methode 1, welke de voorkeur heeft, en niks extra's (EDIT: behalve dan unbound), dan zul je daarvan geen DNS loop ervaren en zullen namen worden weergegeven in de GUI ipv IP's.
Wat is je probleem nu op dit moment precies met wat meer details?
Dit draadje staat bomvol met zaken die je kunt proberen, controleren en testen.

[ Voor 6% gewijzigd door deHakkelaar op 01-01-2022 18:18 ]

[Webgnome]

nero355 schreef op zaterdag 1 januari 2022 @ 17:14:
[...]

Het kan uiteraard een verschil in het gebruikte OS en browser zijn (destijds vs. nu en zo...) maar we weten alweer een tijdje dat als je twee Pi-Hole instances draait dat #2 ook een aardig gedeelte van de queries moet verwerken dus ze worden gewoon beiden gebruikt en de kans op time-outs is dus nog steeds aanwezig!

Zou het het verschil kunnen zijn dat toen jij er last vn had de primaire DNS (volgens het OS) er uit lag waardoor het OS eerst tot in den treure gaat proberen om er dan , te laat, achter te komen dat ie de tweede moet gebruiken?

[deHakkelaar]

@Webgnome , naa denk het niet.
De meeste slimme implementaties sturen initieel een DNS verzoekje naar alle geconfigureerde DNS servers en hanteren dan een algoritme welke DNS server van het lijstje voorkeur heeft voor een bepaalde periode.
Een beetje zoals dat pihole-FTL document welke ik eerder plaatste.
Onderstaand voor oudere Windows versies maar mogelijk dat sommige zaken nog steeds actueel zijn:

The DNS Client service keeps track of which servers answer name queries more quickly, and it moves servers up or down on the list based on how quickly they reply to name queries.

https://docs.microsoft.co...t-2-querying-a-dns-server

[marapuru]

Ik ben een paar weken op vakantie en merk nu hoe verschrikkelijk veel reclame er de hele dag op je afgevuurd wordt. Ben blij als m'n internet filtertje het gewoon weer doet vanuit huis.

Heeft iemand ervaring met een pihole via een eigen VPN eigenlijk?

[deHakkelaar]

@marapuru , zijn je al duizenden voorgegaan.
Twee hapklare smaakjes:
https://docs.pi-hole.net/guides/vpn/wireguard/overview/
https://docs.pi-hole.net/guides/vpn/openvpn/overview/

[deHakkelaar]

@Koepert , je hebt een heleboel details niet vermeldt!
Mocht je Pi-OS Bullseye plus Unbound hebben draaien, dan kan er mogelijk ook een loop onstaan als je niet onderstaande uitvoert:
deHakkelaar in "Raspberry Pi - deel 2"

[ Voor 10% gewijzigd door deHakkelaar op 01-01-2022 19:08 . Reden: unbound linkje toegevoegt ]

[Webgnome]

marapuru schreef op zaterdag 1 januari 2022 @ 18:39:
Ik ben een paar weken op vakantie en merk nu hoe verschrikkelijk veel reclame er de hele dag op je afgevuurd wordt. Ben blij als m'n internet filtertje het gewoon weer doet vanuit huis.

Heeft iemand ervaring met een pihole via een eigen VPN eigenlijk?

Lees dit topic even door en dan ook de laatste reacties van @deHakkelaar. Maar voor wat het waard is. Ik heb zelf een pihole icm wireguard draaien op een pi zero en mijn telefoon gaat het huis niet uit voordat ik die verbonden heb met wireguard. Het werkt echt heerlijk (en supersimpel ).

[Koepert]

deHakkelaar schreef op zaterdag 1 januari 2022 @ 19:01:
@Koepert , je hebt een heleboel details niet vermeldt!
Mocht je Pi-OS Bullseye plus Unbound hebben draaien, dan kan er mogelijk ook een loop onstaan als je niet onderstaande uitvoert:
deHakkelaar in "Raspberry Pi - deel 2"

Excuus ik dacht dat ik (inclusief de historie van eerder deze week) volledig was geweest. Die details stonden idd niet in DIE post, maar waren eerder wel benoemd. Maar de door jou benoemde stappen had ik gevolgd. (mbt Unbound, op een Proxmox Debian VM/Container ipv Pi-OS) Je weet wel..met dat bestandje, wel of niet aanmaken.

Maar even resumerend.

Settings

- Ik heb een Fritzbox 4040 Router;
- Ik heb een Dell Optiplex met Proxmox, waarvan 1 container Pihole is waar ik recent Unbound aan; toegevoegd heb. Unbound (127.0.0.1#5335) is dus de Upstream DNS van de pihole (custom 1 ipv4);
UNbound = https://docs.pi-hole.net/guides/dns/unbound/ + https://www.reddit.com/r/...tm_medium=web2x&context=3 (bij deze 2e staat dit echter niet in /etc/unbound/unbound.conf: maar daar staat [include: "/etc/unbound/unbound.conf.d/*.conf"] in /etc/unbound/unbound.conf.d/pi-hole.conf staan de voorgestelde wijzigingen. Lijkt me dat dat niet uitmaakt;
- Ik heb in Fritzbox (network > network settings > ipv4 settings) het IP van de Pihole als DNS provider. Methode 1 van het linkje zogezegd, zonder port#;
- Ik heb in de Fritzbox (Internet > Account Information > DNS server. "Laat provider dit regelen" (dit is dus methode 2 van je linkje, die heb ik niet uitgevoerd);
- In Pihole staan zowel
Respond only on interface eth0 (Moet dit wellicht op " Allow only local requests" )
Never forward non-FQDN A and AAAA queries
Never forward reverse lookups for private IP ranges
aangevinkt.
- Conditional Forwarding STOND aan. *NU UIT*

Probleem

Dus waar gaat t dan mis? Dit stond met voorsprong in m’n blocked domains.

code:

 domain=lb._dns-sd._udp.0.111.111.111.in-addr.arpa

Waarbij de 111 eigenlijk een variant op m’n ip is dus daarom alle 1tjes. M’n pihole doet geen dhcp..

Daarnaast: Ik krijg de ‘namen’ niet goed. Bijna alles was/is dus [name].fritz.box en er komen ook veel jibberish adressen bij die op IP wel weer terug te leiden zijn maar ook hun Router ‘name’ niet meesturen. Voorbeeld: in de Fritzbox staat onze TV als KD55AG8 met IP .84 en in Pihole als 2357235823592375.fritz.box. Dat wil ik graag netter en daarnaast de loop eruit.

Met Conditional Forwarding UIT (Verder niets gewijzigd) lijkt de loop idd beter (bovengenoemde blocked domain loopt terug) maar zijn de namen nog steeds niet 'mooi' (/duidelijk/herleidbaar).

Ik heb dit topic al meerdere keren doorgelezen maar loop er vooral tegenaan dat ik dus verschillende antwoorden (voor mijn gevoel) lees voor hetzelfde probleem. Ik heb voor mijn gevoel de juiste settings (*en dus Conditional Forwarding AAN voor de namen) maar heb dan een DNS loop (bovenstaande domain) of ik set Conditional Forwarding UIT en heb dan t probleem met de naamgeving.

Dan hoor ik dat je met Local DNS Records dat kunt fixen, maar dat lijkt alleen op basis [name].X(local,home,whatever) te gaan, terwijl ik juist (eigenlijk zoals in AdGuard) gewoon wil zien:

KD55AG8
iPhone Koepert
iPhone Mss Koepert
etc

Als DAT niet kan, is dat OK, maar dat lees ik ook eigenlijk niet echt ergens..


Hopelijk is dit voldoende informatie in 1 post samengevat. Concreet: mijn kennis schiet tekort om hier 100% zelf uit te komen.

[ Voor 12% gewijzigd door Koepert op 01-01-2022 21:06 . Reden: TOEVOEGING ]

[deHakkelaar]

Koepert schreef op zaterdag 1 januari 2022 @ 20:17:
Die details stonden idd niet in DIE post, maar waren eerder wel benoemd.

Bedankt voor de details!
Tis lastig om uit verschillende berichten info te plukken die relevant is en mogelijk in de tusentijd veranderd is.

Koepert schreef op zaterdag 1 januari 2022 @ 20:17:
+ https://www.reddit.com/r/...tm_medium=web2x&context=3

Ik weet niet of dat nou zo verstandig is om de cache uit te schakelen.
Één van de Pi-hole hoofd ontwikkelaars heeft dit een keertje haarfijn uitgelegd op Pi-hole Discourse dat dit niet nodig is.
Beide caches hebben hun voordelen schijnt.
En je moet niet het /etc/dnsmasq.d/01-pihole.conf bestandje handmatig wijzigen:

pi@ph5b:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
###############################################################################
#      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                      #
###############################################################################

Ik heb die redit posting niet verder gelezen omdat er toch al snel twee grove fouten in zitten!

Koepert schreef op zaterdag 1 januari 2022 @ 20:17:
- Ik heb in Fritzbox ....

Ik ken je router niet dus is het lastig voor mij te onderscheiden ofdat je het juist hebt gedaan.
Als je denkt dat het klopt volgens die Pi-hole Fritzbox gids, dan is dat goed genoeg voor mij.

Koepert schreef op zaterdag 1 januari 2022 @ 20:17:
- Conditional Forwarding STOND aan. *NU UIT*

Deze moet weer aan, als dat geen DNS loop veroorzaakt, om IP's naar namen op te lossen en vice versa.
Je zou kunnen testen voor een DNS loop met onderstaande als CF weer aan staat alhoewel de test niet waterdicht is:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

Koepert schreef op zaterdag 1 januari 2022 @ 20:17:
Dus waar gaat t dan mis? Dit stond met voorsprong in m’n blocked domains.

code:

 domain=lb._dns-sd._udp.0.111.111.111.in-addr.arpa

Heb je bovenstaande arpa adres dan in je blocklist staan en waarom?
En van wie/welk IP is dat arpa verzoekje afkomstig dan?
Ter info, dit zijn reverse lookup verzoekjes (IP naar naam):

pi@ph5b:~ $ dig +short @localhost 9.0.0.10.in-addr.arpa ptr
avr.home.dehakkelaar.nl.

EDIT: Dit ziet er logischer uit:

pi@ph5b:~ $ dig +short @localhost -x 10.0.0.9
avr.home.dehakkelaar.nl.

Koepert schreef op zaterdag 1 januari 2022 @ 20:17:
Daarnaast: Ik krijg de ‘namen’ niet goed. Bijna alles was/is dus [name].fritz.box en er komen ook veel jibberish adressen bij die op IP wel weer terug te leiden zijn maar ook hun Router ‘name’ niet meesturen. Voorbeeld: in de Fritzbox staat onze TV als KD55AG8 met IP .84 en in Pihole als 2357235823592375.fritz.box. Dat wil ik graag netter en daarnaast de loop eruit.

Als je Fritzbox DHCP doet, dan is dit de enige plek waar Pi-hole namen van ontdekte client IP's kan achterhalen.
De namen die Pi-hole weergeeft zijn diegenen die met een reverse lookup worden achterhaald.
In mijn geval doet 10.0.0.2 DHCP voor m'n LAN en Pi-hole doet dan iets vergelijkbaars zoals onderstaande om de avr naam achter het 10.0.0.9 IP te achterhalen:

C:\>nslookup 10.0.0.9 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

Dus die naam zou je zelf ff moeten controleren met een nslookup als je het IP van de TV weet.

Koepert schreef op zaterdag 1 januari 2022 @ 20:17:
Dan hoor ik dat je met Local DNS Records dat kunt fixen, maar dat lijkt alleen op basis [name].X(local,home,whatever) te gaan, terwijl ik juist (eigenlijk zoals in AdGuard) gewoon wil zien:

Heb je onderstaande gelezen waarom het niet nodig is om records aan te maken voor DHCP clients?
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

En nslookup is je vriend!

code:

nslookup <HOST_IP> <DNS_SERVER_IP>

Of

code:

nslookup <DOMAIN> <DNS_SERVER_IP>

[Koepert]

deHakkelaar schreef op zaterdag 1 januari 2022 @ 22:03:
[...]

Bedankt voor de details!
Tis lastig om uit verschillende berichten info te plukken die relevant is en mogelijk in de tusentijd veranderd is.

[...]

Ik weet niet of dat nou zo verstandig is om de cache uit te schakelen.
Één van de Pi-hole hoofd ontwikkelaars heeft dit een keertje haarfijn uitgelegd op Pi-hole Discourse dat dit niet nodig is.
Beide caches hebben hun voordelen schijnt.
En je moet niet het /etc/dnsmasq.d/01-pihole.conf bestandje handmatig wijzigen:

pi@ph5b:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
###############################################################################
#      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                      #
###############################################################################

Ik heb die redit posting niet verder gelezen omdat er toch al snel twee grove fouten in zitten!

[...]

Ik ken je router niet dus is het lastig voor mij te onderscheiden ofdat je het juist hebt gedaan.
Als je denkt dat het klopt volgens die Pi-hole Fritzbox gids, dan is dat goed genoeg voor mij.

[...]

Deze moet weer aan, als dat geen DNS loop veroorzaakt, om IP's naar namen op te lossen en vice versa.
Je zou kunnen testen voor een DNS loop met onderstaande als CF weer aan staat alhoewel de test niet waterdicht is:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[...]

Heb je bovenstaande arpa adres dan in je blocklist staan en waarom?
En van wie/welk IP is dat arpa verzoekje afkomstig dan?
Ter info, dit zijn reverse lookup verzoekjes (IP naar naam):

pi@ph5b:~ $ dig +short @localhost 9.0.0.10.in-addr.arpa ptr
avr.home.dehakkelaar.nl.

EDIT: Dit ziet er logischer uit:

pi@ph5b:~ $ dig +short @localhost -x 10.0.0.9
avr.home.dehakkelaar.nl.

[...]

Als je Fritzbox DHCP doet, dan is dit de enige plek waar Pi-hole namen van ontdekte client IP's kan achterhalen.
De namen die Pi-hole weergeeft zijn diegenen die met een reverse lookup worden achterhaald.
In mijn geval doet 10.0.0.2 DHCP voor m'n LAN en Pi-hole doet dan iets vergelijkbaars zoals onderstaande om de avr naam achter het 10.0.0.9 IP te achterhalen:

C:\>nslookup 10.0.0.9 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

Dus die naam zou je zelf ff moeten controleren met een nslookup als je het IP van de TV weet.

[...]

Heb je onderstaande gelezen waarom het niet nodig is om records aan te maken voor DHCP clients?
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

En nslookup is je vriend!

code:

nslookup <HOST_IP> <DNS_SERVER_IP>

Of

code:

nslookup <DOMAIN> <DNS_SERVER_IP>

K zal morgen wat uitgebreider reageren maar:

Dat van dat bestandje had ik wel gezien maar werd ook gezegd: prima dus heb ik dat eerst zo aangepast.

Cache uit was dus idd om snelheid pihole icm unbound te verbeteren..

Ik heb die arpa niet op blacklist gezet maar t verzoek komt van de devices zelf. Bijvoorbeeld

PTR lb._dns-sd._udp.x.1x.168.192.in-addr.arpa iPhoneJeroen.fritz.box Blocked
(external, NXRA) NXDOMAIN (0.6ms)

Dat is dus met conditional forwarding aan. En de overige settings ongewijzigd. Zodra CF aan, beginnen deze requests weer binnen te lopen als blocked. Daarvoor (CF uit) zijn exact dezelfde requests ok


iPhone: mijn iPhone geeft een privacy waarschuwing op dit WiFi met cf aan. Weet niet of dat no n aanwijzing kan zijn.

[ Voor 1% gewijzigd door Koepert op 01-01-2022 22:51 . Reden: Info iPhone ]

[deHakkelaar]

Koepert schreef op zaterdag 1 januari 2022 @ 22:43:
PTR lb._dns-sd._udp.x.1x.168.192.in-addr.arpa iPhoneJeroen.fritz.box Blocked
(external, NXRA) NXDOMAIN (0.6ms)

code:

grep server= -R /etc/dnsmasq.*

???
https://discourse.pi-hole...68-192-in-addr-arpa/46117

[nero355]

Webgnome schreef op zaterdag 1 januari 2022 @ 18:18:
Zou het het verschil kunnen zijn dat toen jij er last vn had de primaire DNS (volgens het OS) er uit lag waardoor het OS eerst tot in den treure gaat proberen om er dan , te laat, achter te komen dat ie de tweede moet gebruiken?

Het is zo lang geleden dat ik dat echt niet meer kan nabootsen of de exacte details nog weet...

Dus dit is allemaal leuk :

deHakkelaar schreef op zaterdag 1 januari 2022 @ 17:29:
@nero355 , hangt idd totaal af van de OS implementatie.
Windows doet bv zoiets als onderstaande:
https://www.ghacks.net/20...me-resolution-in-windows/

deHakkelaar schreef op zaterdag 1 januari 2022 @ 18:24:
@Webgnome , naa denk het niet.
De meeste slimme implementaties sturen initieel een DNS verzoekje naar alle geconfigureerde DNS servers en hanteren dan een algoritme welke DNS server van het lijstje voorkeur heeft voor een bepaalde periode.
Een beetje zoals dat pihole-FTL document welke ik eerder plaatste.
Onderstaand voor oudere Windows versies maar mogelijk dat sommige zaken nog steeds actueel zijn:

[...]

https://docs.microsoft.co...t-2-querying-a-dns-server

Maar dat is allemaal veel te recent en waarschijnlijk niet eens relevant!

Toen ik dat had meegemaakt bestond Windows 7 misschien niet eens...

deHakkelaar schreef op zaterdag 1 januari 2022 @ 17:35:
@nero355 , onderstaand hoe pihole-FTL omgaat met meerder upstream DNS servers:
https://docs.pi-hole.net/...-best-forward-destination

Die ken ik nog wel uit de Changelog van Pi-Hole een jaar of twee a drie geleden geloof ik...

deHakkelaar schreef op zaterdag 1 januari 2022 @ 17:17:
@Eraser127 , als je @nero355 's advies wilt uitvoeren voor Bullseye, hieronder hoe je een boel IP's aan je Pi kan toevoegen (stukje naar beneden scrollen naar dhcpcd-hooks):
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

Ik zou gewoon IP Aliassen configureren in /etc/dhcpcd.conf net zoals ik daarin mijn VLAN sub-interfaces heb staan!

[mrdemc]

Koepert schreef op zaterdag 1 januari 2022 @ 22:43:
[...]


K zal morgen wat uitgebreider reageren maar:

Dat van dat bestandje had ik wel gezien maar werd ook gezegd: prima dus heb ik dat eerst zo aangepast.

Cache uit was dus idd om snelheid pihole icm unbound te verbeteren..

Ik heb die arpa niet op blacklist gezet maar t verzoek komt van de devices zelf. Bijvoorbeeld

PTR lb._dns-sd._udp.x.1x.168.192.in-addr.arpa iPhoneJeroen.fritz.box Blocked
(external, NXRA) NXDOMAIN (0.6ms)

Dat is dus met conditional forwarding aan. En de overige settings ongewijzigd. Zodra CF aan, beginnen deze requests weer binnen te lopen als blocked. Daarvoor (CF uit) zijn exact dezelfde requests ok


iPhone: mijn iPhone geeft een privacy waarschuwing op dit WiFi met cf aan. Weet niet of dat no n aanwijzing kan zijn.

Wat is de DHCP range van de fritzbox en wat heb je in de PiHole onder de conditional forwarding checkbox in de velden ingevuld? Want die melding zegt mij dat de upstream server het request blocked. En de upstream hoort deze request niet te krijgen want het hoort naar de fritzbox te gaan.

[ Voor 56% gewijzigd door mrdemc op 02-01-2022 02:04 . Reden: Verkeerd bericht gequoted ]

[Koepert]

deHakkelaar schreef op zaterdag 1 januari 2022 @ 23:38:
[...]

code:

grep server= -R /etc/dnsmasq.*

???
https://discourse.pi-hole...68-192-in-addr-arpa/46117

code:

/etc/dnsmasq.d/06-rfc6761.conf:server=/test/
/etc/dnsmasq.d/06-rfc6761.conf:server=/localhost/
/etc/dnsmasq.d/06-rfc6761.conf:server=/invalid/
/etc/dnsmasq.d/06-rfc6761.conf:server=/bind/
/etc/dnsmasq.d/06-rfc6761.conf:server=/onion/
/etc/dnsmasq.d/01-pihole.conf:server=127.0.0.1#5335
/etc/dnsmasq.d/01-pihole.conf:rev-server=192.168.178.0/24,192.168.178.1

Overigens, bijna alle aanvragen naar dit adres zijn idd Apples.. maar in de link die je stuurt zie ik zo geen oplossing? Als ik dit lees: https://discourse.pi-hole...ud-private-relay/49811/26
Zouden die 2 NXDOMAIN entries een oplossing kunnen zijn?

[ Voor 7% gewijzigd door Koepert op 02-01-2022 09:55 . Reden: Apple link added ]

[Koepert]

mrdemc schreef op zondag 2 januari 2022 @ 01:59:
[...]


Wat is de DHCP range van de fritzbox en wat heb je in de PiHole onder de conditional forwarding checkbox in de velden ingevuld? Want die melding zegt mij dat de upstream server het request blocked. En de upstream hoort deze request niet te krijgen want het hoort naar de fritzbox te gaan.

Nu je t zegt, zie ik dit pas:

CF settings: 192.168.178.0/24 & 192.168.178.1 (local domain = optie, heb ik leeg gelaten)
Router settings DHCP 192.1168.178.20 - 200

Zou daar wat kunnen zitten ? Dat DHCP daar pas bij 20 begint?

[Koepert]

deHakkelaar schreef op zaterdag 1 januari 2022 @ 22:03:
[...]

Bedankt voor de details!
Tis lastig om uit verschillende berichten info te plukken die relevant is en mogelijk in de tusentijd veranderd is.

[...]

Ik weet niet of dat nou zo verstandig is om de cache uit te schakelen.
Één van de Pi-hole hoofd ontwikkelaars heeft dit een keertje haarfijn uitgelegd op Pi-hole Discourse dat dit niet nodig is.
Beide caches hebben hun voordelen schijnt.
En je moet niet het /etc/dnsmasq.d/01-pihole.conf bestandje handmatig wijzigen:

pi@ph5b:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
###############################################################################
#      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                      #
###############################################################################

Ik heb die redit posting niet verder gelezen omdat er toch al snel twee grove fouten in zitten!

Dit heb ik dus maar weer teruggedraaid. Lijkt me idd sowieso van tijdelijke aard als een update het bestand overschrijft.

[...]

Ik ken je router niet dus is het lastig voor mij te onderscheiden ofdat je het juist hebt gedaan.
Als je denkt dat het klopt volgens die Pi-hole Fritzbox gids, dan is dat goed genoeg voor mij.

Dankje, maar ja, ik volgt die stappen en dat is exact wat ik gedaan heb.

[...]

Deze moet weer aan, als dat geen DNS loop veroorzaakt, om IP's naar namen op te lossen en vice versa.
Je zou kunnen testen voor een DNS loop met onderstaande als CF weer aan staat alhoewel de test niet waterdicht is:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

Deze test heb ik gedraaid en daar komt 0 respons, dus dan is er wellicht geen loop, maar alleen veel van die requests..als ik echter handmatig in de log kijk, zie ik veel dit:

code:

Jan  2 00:40:47 dnsmasq[14526]: query[PTR] lb._dns-sd._udp.0.178.168.192.in-addr.arpa from 192.168.178.80
Jan  2 00:40:47 dnsmasq[14526]: forwarded lb._dns-sd._udp.0.178.168.192.in-addr.arpa to 192.168.178.1
Jan  2 00:40:47 dnsmasq[14526]: query[PTR] lb._dns-sd._udp.fritz.box from 192.168.178.80

Dat is toch feitelijk een loop ? .1 is mijn router, .80 mijn iphone.

[...]

Heb je bovenstaande arpa adres dan in je blocklist staan en waarom?
En van wie/welk IP is dat arpa verzoekje afkomstig dan?

Dit lijken alleen maar verzoekjes van onzer beider iPhones te zijn. Zoals gezegd, geven die ook een privacywaarschuwing bij dit wifi netwerk:

code:

Dit verkeer blokkeert versleuteld DNS_verkeer.

Dat lijkt aan " privedoorgifte" te liggen, maar die kan ik niet uit zetten omdat ik dan eerst een abo moet afsluiten

Ter info, dit zijn reverse lookup verzoekjes (IP naar naam):

pi@ph5b:~ $ dig +short @localhost 9.0.0.10.in-addr.arpa ptr
avr.home.dehakkelaar.nl.

EDIT: Dit ziet er logischer uit:

pi@ph5b:~ $ dig +short @localhost -x 10.0.0.9
avr.home.dehakkelaar.nl.

[...]

Als je Fritzbox DHCP doet, dan is dit de enige plek waar Pi-hole namen van ontdekte client IP's kan achterhalen.
De namen die Pi-hole weergeeft zijn diegenen die met een reverse lookup worden achterhaald.
In mijn geval doet 10.0.0.2 DHCP voor m'n LAN en Pi-hole doet dan iets vergelijkbaars zoals onderstaande om de avr naam achter het 10.0.0.9 IP te achterhalen:

C:\>nslookup 10.0.0.9 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

Dus die naam zou je zelf ff moeten controleren met een nslookup als je het IP van de TV weet.

[...]

Heb je onderstaande gelezen waarom het niet nodig is om records aan te maken voor DHCP clients?
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

En nslookup is je vriend!

code:

nslookup <HOST_IP> <DNS_SERVER_IP>

Of

code:

nslookup <DOMAIN> <DNS_SERVER_IP>

Mja, dat lijkt dan ook wel weer ok..

[ Voor 4% gewijzigd door Koepert op 02-01-2022 10:07 ]

[roT-]

Ik draai al een paar jaar 2 piholes in een vm. Werkt helemaal prima. Tot in de puntjes geconfigt oftewel set and forget.

Enige wat ik merk bij een pihole-up dat sommige blocklists niet meer updaten/reageren. Is inmiddels een nieuwe favorieten verzameling blocklists die jullie gebruiken? Momenteel blockt mijn pihole setje zo’n 4,5 miljoen domeinen.

Ik ben me bewust dat dit wel een vraag zal zijn die vaak gesteld wordt haha

[Webgnome]

roT- schreef op zondag 2 januari 2022 @ 10:09:
Ik ben me bewust dat dit wel een vraag zal zijn die vaak gesteld wordt haha

Dan heb ik maar één antwoord: Zoek het topic even door

[dragon2]

Vraagje, of ik dit een beetje 'goed heb gedaan':

Ik heb sinds een week een raspberry pi zero 2W draaien met pi hole erop.
Dus met putty aan de slag enzo, lekker fröbelen.

Mijn router (Xiaomi Mi AX3600) heeft alleen erg weinig mogelijkheden 😐 nou ja de ledjes kunnen uit 🤣, dus de pi zelf maar een vast ip gegeven in de hoop dat dat goed blijft gaan.
DNS1 in de router op het ip adres van de pi gezet.
DNS2 is leeg.

Hele netwerk loopt nu dus als het goed is via de pi.

Ik liep tegen wat dingetjes aan, bv NOS app die niet meer wilde en Spotify casten via alexa en Google Home ging niet meer, dat allemaal gefixt. Beetje jammer wel dat reclame in YouTube niet wil verdwijnen 🙁 maar dat is dan blijkbaar zo.

Al best trots op eigenlijk wat er nu draait 😊

Maarreh, gezien ik hier dus verder echt 0 verstand van heb, ziet iemand ergens steken die ik heb laten vallen?

[ Voor 5% gewijzigd door dragon2 op 02-01-2022 11:34 ]

[Webgnome]

dragon2 schreef op zondag 2 januari 2022 @ 11:33:
Vraagje, of ik dit een beetje 'goed heb gedaan':
...

Mijn router (Xiaomi Mi AX3600) heeft alleen erg weinig mogelijkheden 😐 nou ja de ledjes kunnen uit 🤣, dus de pi zelf maar een vast ip gegeven in de hoop dat dat goed blijft gaan.
DNS1 in de router op het ip adres van de pi gezet.
DNS2 is leeg.

Hele netwerk loopt nu dus als het goed is via de pi.

Ja, waarschijnlijk wel. Dit kun je testen door een domein dat op je blocklist staat proberen te openen. Lukt dat niet dan werkt pi-hole zoals het zou moeten

dragon2 schreef op zondag 2 januari 2022 @ 11:33:
Ik liep tegen wat dingetjes aan, bv NOS app die niet meer wilde en Spotify casten via alexa en Google Home ging niet meer, dat allemaal gefixt.

dragon2 schreef op zondag 2 januari 2022 @ 11:33:
Beetje jammer wel dat reclame in YouTube niet wil verdwijnen 🙁 maar dat is dan blijkbaar zo.

Had je de topicwaarschuwing ook gelezen of?

dragon2 schreef op zondag 2 januari 2022 @ 11:33:
Maarreh, gezien ik hier dus verder echt 0 verstand van heb, ziet iemand ergens steken die ik heb laten vallen?

zonder meer informatie kunnen wij niet zien wat het doel was dat je had met de installatie van pihole en wat er dan dus nog zou missen

[dragon2]

Webgnome schreef op zondag 2 januari 2022 @ 11:57:
[...]

Ja, waarschijnlijk wel. Dit kun je testen door een domein dat op je blocklist staat proberen te openen. Lukt dat niet dan werkt pi-hole zoals het zou moeten


[...]




[...]


Had je de topicwaarschuwing ook gelezen of?


[...]


zonder meer informatie kunnen wij niet zien wat het doel was dat je had met de installatie van pihole en wat er dan dus nog zou missen

Mijn doel was de s***load aan reclame in te dammen. Ik scroll vaak snel door forums en dan klik ik weer per ongeluk een advertie aan of het scrollen gaat niet lekker omdat advertenties trager laden

En YouTube dus, maar helaas, daar was ik dus ondertussen zelf al achtergekomen

Echt heel handig van mij, ik ben dit topic pas gaan volgen toen ik de mijne al had draaien

Die YouTube reclame heb ik wel wat gegoogelde dingen voor geprobeerd. Ik heb wel het idee dat het een stukje minder is dan vantevoren, maar dat kan ook wishful thinking zijn

[Webgnome]

Er zijn twee opties die echt goed werken tegen youtube adds

- Geen youtube meer gebruiken
- Youtube premium nemen

offtopic:
Zelf heb ik een premium abonnement. Aangezien ik het dagelijks gebruik lijkt het mij niet meer dan zinvol dat te doen

[ Voor 35% gewijzigd door Webgnome op 02-01-2022 12:24 ]

[Koepert]

Webgnome schreef op zondag 2 januari 2022 @ 12:23:
Er zijn twee opties die echt goed werken tegen youtube adds

- Geen youtube meer gebruiken
- Youtube premium nemen

offtopic:
Zelf heb ik een premium abonnement. Aangezien ik het dagelijks gebruik lijkt het mij niet meer dan zinvol dat te doen

Ublock Origin icm inlogaccount ook wel

[Freee!!]

dragon2 schreef op zondag 2 januari 2022 @ 11:33:
Vraagje, of ik dit een beetje 'goed heb gedaan':

Ik heb sinds een week een raspberry pi zero 2W draaien met pi hole erop.
Dus met putty aan de slag enzo, lekker fröbelen.

Mijn router (Xiaomi Mi AX3600) heeft alleen erg weinig mogelijkheden 😐 nou ja de ledjes kunnen uit 🤣, dus de pi zelf maar een vast ip gegeven in de hoop dat dat goed blijft gaan.
DNS1 in de router op het ip adres van de pi gezet.
DNS2 is leeg.

Hele netwerk loopt nu dus als het goed is via de pi.

Ik liep tegen wat dingetjes aan, bv NOS app die niet meer wilde en Spotify casten via alexa en Google Home ging niet meer, dat allemaal gefixt. Beetje jammer wel dat reclame in YouTube niet wil verdwijnen 🙁 maar dat is dan blijkbaar zo.

Al best trots op eigenlijk wat er nu draait 😊

Maarreh, gezien ik hier dus verder echt 0 verstand van heb, ziet iemand ergens steken die ik heb laten vallen?

Ik zou in DNS2 ook het ip-adres van de Pi zetten.

[mrdemc]

Koepert schreef op zondag 2 januari 2022 @ 09:30:
[...]


Nu je t zegt, zie ik dit pas:

CF settings: 192.168.178.0/24 & 192.168.178.1 (local domain = optie, heb ik leeg gelaten)
Router settings DHCP 192.1168.178.20 - 200

Zou daar wat kunnen zitten ? Dat DHCP daar pas bij 20 begint?

Dat zou goed moeten werken, volgens AVM is het wel een /24 en is het puur de DHCP server die de 20-200 uitgeeft. Je zou dan bijv. een statisch IP kunnen instellen voor een apparaat buiten de DHCP scope. IP van de router klopt ook, maar je zou kunnen proberen wat er gebeurt als je in domain "fritz.box" invoert.

Daarnaast zou ik het vinkje bij "Never forward reverse lookups for private IP ranges" uitzetten. Zie ook in dat scherm de opmerking die eronder staat:

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.

[deHakkelaar]

Koepert schreef op zondag 2 januari 2022 @ 09:28:
Overigens, bijna alle aanvragen naar dit adres zijn idd Apples.. maar in de link die je stuurt zie ik zo geen oplossing?

In dat PH Discourse linkje die ik plaatste was er onderstaande config bestandje aanwezig, welke niet bij Pi-hole hoort, waardoor reverse lookups voor 192.168.0.x adressen terug loept naar het Pi-hole IP 192.168.0.200 :

/etc/dnsmasq.d/10-lan-domain.conf:1:server=/att.com/192.168.0.200
/etc/dnsmasq.d/10-lan-domain.conf:2:server=/0.168.192.in-addr.arpa/192.168.0.200

Oplossing daar zou zijn geweest om gewoon bovenstaande bestandje te verwijderen.

Koepert schreef op zondag 2 januari 2022 @ 09:28:
Als ik dit lees: https://discourse.pi-hole...ud-private-relay/49811/26
Zouden die 2 NXDOMAIN entries een oplossing kunnen zijn?

Dat ziet er uit als een ander probleem dan welke jij nu ervaart.
En zo te zien zijn die kanarie domeinen al standaard verwerkt in de huidige pihole-FTL versie:

pi@ph5b:~ $ dig @localhost mask.icloud.com
[..]
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53129

Tov bv Google DNS @ 8.8.8.8 vragen:

pi@ph5b:~ $ dig @8.8.8.8 mask.icloud.com
[..]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41034
[..]
;; ANSWER SECTION:
mask.icloud.com.        3064    IN      CNAME   mask.apple-dns.net.
mask.apple-dns.net.     60      IN      A       17.248.176.72
mask.apple-dns.net.     60      IN      A       17.248.176.70
mask.apple-dns.net.     60      IN      A       17.248.176.73
mask.apple-dns.net.     60      IN      A       17.248.176.5
mask.apple-dns.net.     60      IN      A       17.248.176.4
mask.apple-dns.net.     60      IN      A       17.248.176.71
mask.apple-dns.net.     60      IN      A       17.248.176.9
mask.apple-dns.net.     60      IN      A       17.248.176.7

Koepert schreef op zondag 2 januari 2022 @ 09:30:
CF settings: 192.168.178.0/24 & 192.168.178.1 (local domain = optie, heb ik leeg gelaten)
Router settings DHCP 192.1168.178.20 - 200

Zou daar wat kunnen zitten ? ...

Mogelijk.
Ik zou ook het "local domain" configureren zelfs al is dit mogelijk niet gerelateerd met je huidige probleem.
Door dat "local domain" op te geven verhinder je namelijk dat bepaalde verzoekjes ongewenst kunnen lekken naar je upstream geconfigureerde DNS server(s).
Maar alleen als ook de "Never forward non-FQDN A and AAAA queries" Pi-hole instelling aan staat!
Deze "local domain" kun je achterhalen met onderstaande (is geloof ik fritz.box voor jou):

pi@ph5b:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
   domain-name: "home.dehakkelaar.nl"

Koepert schreef op zondag 2 januari 2022 @ 09:42:
Dit heb ik dus maar weer teruggedraaid. Lijkt me idd sowieso van tijdelijke aard als een update het bestand overschrijft.

Eigen opties/directives voor de embedded dnsmasq kun je in een appart nieuw bestandje plaatsen bv /etc/dnsmasq.d/99-my-settings.conf.

Koepert schreef op zondag 2 januari 2022 @ 09:42:
Deze test heb ik gedraaid en daar komt 0 respons, dus dan is er wellicht geen loop, ...

Zoals ik al eerder melde, die dns-loop-detect test alleen met TXT DNS records en niet met PTR records (voor reverse lookups) waar nu je probleem zit.

Koepert schreef op zondag 2 januari 2022 @ 09:42:

code:

Jan  2 00:40:47 dnsmasq[14526]: query[PTR] lb._dns-sd._udp.0.178.168.192.in-addr.arpa from 192.168.178.80
Jan  2 00:40:47 dnsmasq[14526]: forwarded lb._dns-sd._udp.0.178.168.192.in-addr.arpa to 192.168.178.1
Jan  2 00:40:47 dnsmasq[14526]: query[PTR] lb._dns-sd._udp.fritz.box from 192.168.178.80

Dat is toch feitelijk een loop ? .1 is mijn router, .80 mijn iphone.

Niet zoals het er nu uitziet.
Die lb._dns-sd._udp.0.178.168.192.in-addr.arpa PTR verzoekjes worden door pihole-FTL ge-forward naar je router 192.168.178.1.
Maar je router loept deze verzoekjes niet weer terug naar het Pi-hole IP ... als goed is

Koepert schreef op zondag 2 januari 2022 @ 09:42:
Zoals gezegd, geven die ook een privacywaarschuwing bij dit wifi netwerk:

Die waarchuwing krijg je vermoedelijk te zien omdat pihole-FTL op verzoekjes met dat mask.icloud.com domein antwoord met NXDOMAIN zoals boven beschreven.

Koepert schreef op zondag 2 januari 2022 @ 09:42:

code:

Jan  2 00:40:47 dnsmasq[14526]: query[PTR] lb._dns-sd._udp.fritz.box from 192.168.178.80

Kijk ofdat je probleem verdwijnt als je ook het "local domain" configureerd in de conditional forwarding instellingen?
Zonder dit "local domain" probeert pihole-FTL vermoedelijk bovenstaande zelf op te lossen ipv te forwarden naar je router IP.

EDIT: Ow en ik zou de logs in de gaten houden ipv de data op de web GUI!
De logs geven iets meer details.
Je kunt de logs live volgen met onderstaande:

code:

pihole -t

Of met less door de logs browsen:

code:

less /var/log/pihole.log

[deHakkelaar]

mrdemc schreef op zondag 2 januari 2022 @ 13:28:
Daarnaast zou ik het vinkje bij "Never forward reverse lookups for private IP ranges" uitzetten. Zie ook in dat scherm de opmerking die eronder staat:

Is niet nodig.
Pi-hole maakt een uitzondering voor IP's geconfigureerd in het "Local network in CIDR notation" CF veldje en forward deze dan wel ipv dat ze worden tegengehouden.

EDIT: Ow en ook een uitzondering voor lookups voor/met het "Local domain name" veldje in de CF instellingen!

[ Voor 13% gewijzigd door deHakkelaar op 02-01-2022 15:58 ]

[mrdemc]

deHakkelaar schreef op zondag 2 januari 2022 @ 14:23:
[...]

Is niet nodig.
Pi-hole maakt een uitzondering voor IP's geconfigureerd in het "Local network in CIDR notation" CF veldje en forward deze dan wel ipv dat ze worden tegengehouden.

Dat zou je inderdaad wel zeggen (logischerwijs), maar ik lees dat nergens expliciet (ik lees wel: "if the Pi-hole is not used as DHCP server.", en dat is het geval) en dat is naar het lijkt ook niet wat er hier gebeurd, dus vandaar dat dit wel iets is om na te gaan m.i.

Ik denk wel dat het instellen van de domain het meeste effect zal hebben in dit geval.

[ Voor 7% gewijzigd door mrdemc op 02-01-2022 14:31 ]

[tvtech]

En als je nu gewoon eens Adguard installeerd op je telefoon en of laptop, dus lokaal op je device Adguard draaien. Als je dan youtube in je browser draait kun je ook advertenties blokkeren. Adguard als app kun je ook automatisch aan laten zetten zodra je van je eigen wifi af gaat.

[deHakkelaar]

mrdemc schreef op zondag 2 januari 2022 @ 14:28:
Dat zou je inderdaad wel zeggen (logischerwijs) ...

Node één van twee (welke ook DHCP doet) met unbound als upstream:







------------------

Node twee van twee met unbound:







LAN namen en IP's worden gewoon opgelost vanaf een client (EDIT: via beide Pi-hole IP's):

C:\>nslookup avr 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

C:\>nslookup avr 10.0.0.4
Server:  pi.hole
Address:  10.0.0.4

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

C:\>nslookup 10.0.0.9 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

C:\>nslookup 10.0.0.9 10.0.0.4
Server:  pi.hole
Address:  10.0.0.4

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

[ Voor 4% gewijzigd door deHakkelaar op 02-01-2022 14:52 ]

[mrdemc]

deHakkelaar schreef op zondag 2 januari 2022 @ 14:39:
[...]


Node één van twee (welke ook DHCP doet) met unbound als upstream:

[Afbeelding]

[Afbeelding]

[Afbeelding]

------------------

Node twee van twee met unbound:

[Afbeelding]

[Afbeelding]

[Afbeelding]

LAN namen en IP's worden gewoon opgelost vanaf een client (EDIT: via beide Pi-hole IP's):

C:\>nslookup avr 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

C:\>nslookup avr 10.0.0.4
Server:  pi.hole
Address:  10.0.0.4

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

C:\>nslookup 10.0.0.9 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

C:\>nslookup 10.0.0.9 10.0.0.4
Server:  pi.hole
Address:  10.0.0.4

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

Goed om te weten! Nu weet ik natuurlijk niet hoe de rest van jouw configuratie eruit ziet, maar ik ga er even voor het gemak vanuit dat dat geen verdere invloed heeft

[deHakkelaar]

mrdemc schreef op zondag 2 januari 2022 @ 14:58:
Nu weet ik natuurlijk niet hoe de rest van jouw configuratie eruit ziet, ...

DHCP op node één:


Op node twee is de DHCP service uitgeschakeld.
Wat wil je nog meer zien?

[ Voor 3% gewijzigd door deHakkelaar op 02-01-2022 15:08 ]

[deHakkelaar]

nero355 schreef op zondag 2 januari 2022 @ 00:30:
Ik zou gewoon IP Aliassen configureren in /etc/dhcpcd.conf net zoals ik daarin mijn VLAN sub-interfaces heb staan!

Ik had voorheen al proberen uit te leggen dat dit niet meer optimaal werkt met Pi-OS Bullseye:

deHakkelaar schreef op maandag 6 december 2021 @ 06:40:
Ik wou ff testen door een extra alias IP toe te voegen via onderstaande methode:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"
Maar dat werkt niet meer optimaal met de laatste Pi-OS Bullseye (twee dezelfde adressen):

pi@ph5b:~ $ ip -br -4 address
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.0.4/24
eth0.0@eth0      UP             10.0.0.4/24 10.10.10.10/24

Vandaar de dhcpcd-hooks methode.

[deHakkelaar]

@mrdemc , was vergeten te melden dat ik de DHCP service van Pi-hole node 1 heb geconfigureerd met onderstaande om beide Pi-hole nodes als DNS servers te adverteren:

pi@ph5a:~ $ sudo nano /etc/dnsmasq.d/10-dhcp-dns.conf
dhcp-option=option:dns-server,10.0.0.2,10.0.0.4

[nero355]

dragon2 schreef op zondag 2 januari 2022 @ 11:33:
Mijn router (Xiaomi Mi AX3600) heeft alleen erg weinig mogelijkheden nou ja de ledjes kunnen uit

Kijk dan eens of je iets van een WRT smaakje erop kan flashen zoals OpenWRT of DD-WRT en zo!

Maar als ik heel eerlijk ben heb je sowieso de verkeerde router gekocht, want zo'n beetje elke Xiaomi Router die ik heb bekeken is totaal niet optimaal qua WiFi voor de Nederlandse/Belgische/Europese markt!

tvtech schreef op zondag 2 januari 2022 @ 14:33:
En als je nu gewoon eens Adguard installeerd op je telefoon en of laptop, dus lokaal op je device Adguard draaien. Als je dan youtube in je browser draait kun je ook advertenties blokkeren. Adguard als app kun je ook automatisch aan laten zetten zodra je van je eigen wifi af gaat.

AdGuard is een vies woord in dit topic!

Als je toch al wat op je telefoon wilt hebben qua adblocking :
- PiVPN + Pi-Hole op je eigen netwerk.
- Blokada
- Firefox for Android met uBlock Origin

deHakkelaar schreef op zondag 2 januari 2022 @ 15:22:
[...]

Ik had voorheen al proberen uit te leggen dat dit niet meer optimaal werkt met Pi-OS Bullseye:

[...]

Vandaar de dhcpcd-hooks methode.

Dan wordt het tijd om eindelijk /etc/dhcpcd.conf te slopen en terug te gaan naar /etc/network/interfaces zoals we altijd al deden!

Hebben we het geloof ik zelfs een paar keer over gehad in dit topic...

[deHakkelaar]

nero355 schreef op zondag 2 januari 2022 @ 16:08:
Dan wordt het tijd om eindelijk /etc/dhcpcd.conf te slopen en terug te gaan naar /etc/network/interfaces zoals we altijd al deden!

Hebben we het geloof ik zelfs een paar keer over gehad in dit topic...

Ja maar dan wordt elke keer weer dhcpcd5 geinstalleerd bij een Pi-hole repair/update.
Heb nog niet gekeken hoe dit te omzeilen

[nero355]

deHakkelaar schreef op zondag 2 januari 2022 @ 16:17:
Ja maar dan wordt elke keer weer dhcpcd5 geinstalleerd bij een Pi-hole repair/update.
Heb nog niet gekeken hoe dit te omzeilen

Kunnen we die niet gewoon On Hold gooien of zo

Volgens mij moet dat wel te fixen zijn...

[deHakkelaar]

@nero355 , mogelijk dat Pi-hole repair/update dan struikelt als deze niet te installeren valt.
Nu ik weet hoe het te doen met dhcp-hooks, laat dan maar al die moeite

[ Voor 4% gewijzigd door deHakkelaar op 02-01-2022 16:24 ]

[dragon2]

Freee!! schreef op zondag 2 januari 2022 @ 13:06:
[...]

Ik zou in DNS2 ook het ip-adres van de Pi zetten.

Net gedaan. Heb je er ook uitleg bij waarom dat beter is?

nero355 schreef op zondag 2 januari 2022 @ 16:08:
[...]

Kijk dan eens of je iets van een WRT smaakje erop kan flashen zoals OpenWRT of DD-WRT en zo!

Maar als ik heel eerlijk ben heb je sowieso de verkeerde router gekocht, want zo'n beetje elke Xiaomi Router die ik heb bekeken is totaal niet optimaal qua WiFi voor de Nederlandse/Belgische/Europese markt!


[...]

AdGuard is een vies woord in dit topic!

Als je toch al wat op je telefoon wilt hebben qua adblocking :
- PiVPN + Pi-Hole op je eigen netwerk.
- Blokada
- Firefox for Android met uBlock Origin




[...]

Ik had 2x netgear r7000, maar degene die ingesteld was als router (met dd wrt erop) verloor op een gegeven moment steeds z'n config 😐

Dus toen even snel een betaalbare vervanging gescoord.
Op zich bevalt de WiFi van de xiaomi wel hoor, lijkt me iig niet slechter dan de r7000. Ik heb een beetje idioot veel netwerkapparaten in huis (naast laptops, foons, tablets etc ook servers, printers, allerlei hubs, echo en google home spreakers, eufy bel en rijtje cams, enz). De standaard tmobile router was daar niet echt blij mee, dus die ligt allang in een la.

Wel beetje rare Router die xiaomi: toegang alleen via een (dus nogal beperkte) app en af en toe krijg ik meldingen/vragen in het Chinees (??).

Ik heb wel gigabit Internet dus als ik hier en daar wat kwijtraak, door router, pi of wat anders, ach 🤷

Vwb YouTube, dat gaat hier bijna altijd via TV en/of shield (allen android TV).

[deHakkelaar]

dragon2 schreef op zondag 2 januari 2022 @ 16:25:
... af en toe krijg ik meldingen/vragen in het Chinees (??).

Wen er alvast maar aan!
Over tien jaar ofzo wordt zoiezo van je verwacht dit te kunnen lezen

[ Voor 14% gewijzigd door deHakkelaar op 02-01-2022 16:30 ]

[Freee!!]

dragon2 schreef op zondag 2 januari 2022 @ 16:25:
[...]
Net gedaan. Heb je er ook uitleg bij waarom dat beter is?

Gaat dat apparaat niet stiekem DNS-providers van je ISP doorgeven (er zijn apparaten, die dat doen als er geen twee DNS-servers zijn ingevuld).

[nero355]

deHakkelaar schreef op zondag 2 januari 2022 @ 16:24:
mogelijk dat Pi-hole repair/update dan struikelt als deze niet te installeren valt.

Tijd voor een bug submit dan!

dragon2 schreef op zondag 2 januari 2022 @ 16:25:
Ik had 2x netgear r7000, maar degene die ingesteld was als router (met dd wrt erop) verloor op een gegeven moment steeds z'n config

Dat is wel gek... maar dat moet toch haast wel een bug zijn geweest

Anders effe een ander smaakje WRT erop flashen en opnieuw proberen!

De R7000 is een hele mooie Router geweest toen die net uitkwam, maar helaas heeft Netgear hem stap voor stap gesloopt gedurende een tijd door slechte firmwares uit te brengen dus welke firmware het beste erop werkt durf ik zo gauw niet te zeggen, echter zijn er genoeg third party firmwares ervoor te verkrijgen als het goed is...

Op zich bevalt de WiFi van de xiaomi wel hoor, lijkt me iig niet slechter dan de r7000. Ik heb een beetje idioot veel netwerkapparaten in huis (naast laptops, foons, tablets etc ook servers, printers, allerlei hubs, echo en google home spreakers, eufy bel en rijtje cams, enz). De standaard tmobile router was daar niet echt blij mee, dus die ligt allang in een la.

De frequenties/channels van de Xiaomi Routers zijn over het algemeen erg beperkt en daardoor IMHO niet geschikt voor onze markt!

Wel beetje rare Router die xiaomi: toegang alleen via een (dus nogal beperkte) app en af en toe krijg ik meldingen/vragen in het Chinees (??).

Nog meer reden om wat anders erop te flashen!

Netwerkapparaten die afhankelijk zijn van een domme app zouden verboden moeten worden!

Ik heb wel gigabit Internet dus als ik hier en daar wat kwijtraak, door router, pi of wat anders, ach...

Ook zonde!

Vwb YouTube, dat gaat hier bijna altijd via TV en/of shield (allen android TV).

Dan installeer je een alternatieve YouTube Client gewoon!

Zie de TS van [Nvidia Shield] Ervaringen & Discussie

[michelk31]

Tot op heden heb ik altijd diversion gebruikt om adds te blocken via Merlinwrt.
Diversion heb ik voorlopig disabled via amtm.

Vandaag heb ik via docker station op een QNAP NAS PI-Hole geinstalleerd.
Op mijn vaste pc werkt de PI-hole zeer goed.
Ik heb nu echter het probleem dat ik mijn android telefoon niet verbonden krijg op de PI-HOLE.
Ik voer de volgende instellingen in op android:

IP-instelling ⇾ statisch
IP 192.168.1.24 (deze is vrij)
Gateway 192.168.1.1
DNS 192.168.1.50 (PI-Hole adres)

Hierna geeft de android telefoon aan dat de router geen toegang heeft tot het internet .

Wanneer ik de IP-instelling verander naar DHCP dan heb ik terug internet.
Ik kan dan ook via de telefoon inloggen op de PI-Hole .

Heeft iemand enig idee wat ik mis doe?

[ Voor 11% gewijzigd door michelk31 op 02-01-2022 17:54 ]

[Webgnome]

Kun je de dns niet simpelweg via dhcp laten doorgeven?

[michelk31]

Webgnome schreef op zondag 2 januari 2022 @ 18:06:
Kun je de dns niet simpelweg via dhcp laten doorgeven?

Hij bedankt voor de feedback.
Mij kennis is echter beperkt met betrekking tot IT.
Hoe kan ik dit realiseren?

[michelk31]

michelk31 schreef op zondag 2 januari 2022 @ 18:10:
[...]


Hij bedankt voor de feedback.
Mij kennis is echter beperkt met betrekking tot IT.
Hoe kan ik dit realiseren?

Wacht ik heb het volgende gewijzigd in mijn asus router.
Advanced settings LAN -> DHCP server -> dns server 1 -> ingesteld op 192.168.1.50.

Ik heb het gevoel dat dit werkt.
Ik ga nu het verder testen.

[Webgnome]

Dat is inderdaad de instelling die je nodig had / hebt. Als je nog een dns server kan ingeven ( ga ik even van uit aangezien er staat dns server 1) zou je daar je pihole ook in kunnen geven. Dan weet je zeker dat dat goed gaat.

[michelk31]

Webgnome schreef op zondag 2 januari 2022 @ 18:22:
Dat is inderdaad de instelling die je nodig had / hebt. Als je nog een dns server kan ingeven ( ga ik even van uit aangezien er staat dns server 1) zou je daar je pihole ook in kunnen geven. Dan weet je zeker dat dat goed gaat.

Bedankt

[Koepert]

Kut. Ik heb unbound om zeep (failed met een restart to quickly error).

Had vanavond problemen met netwerk. Proxmox met NGINX container #1 pihole #2 en adguard (uit) #3. Om pihole problemen te testen > adguard aan en unbound. Nou.. iPhone ‘loop’ (overdaad aan verzoekjes) was er niet maar wel 20% ipv 7% RAM op zelfde specs. Dus wilde ik terug naar pihole. Dns router weer om, NGINX van vm naar container in the process. Die kwam niet up. Port 80 al in use. Laaaaang zoeken.. bleek dat bij reuppen er een tweede instance was ‘ontstaan’. Geen idee maar die gekilled en voila ik kan weer van buiten bij m’n Home Assistant… maar geen internet. Opeens.. crap. Pihole draait. Adguard uit. Blijkt unbound niet meer te starten/draaien. Dus nu ff terug naar cloudflare (nog steeds met veel iPhone requests). En dan kijken of ik me focus op die iPhone of unbound issues. Nu zag ik wel. De container gebruikt de dns van de proxmox host net als elke container en vm. De host gebruikt de dns van de pihole container. Maar ik meende dat dat met een reden was … weet alleen niet welke… kan dat ook dit veroorzaakt hebben ? Of weet iemand waarom dit zou zijn? (Ja ja I know. Zou t zelf moeten weten. )

[jpgview]

Een aantal maanden geleden schreef ik hier hoe je met behulp van pfsense (of andere firewall met uitgebreide mogelijkheden) er kan voor zorgen dat DoH (DNS over HTTPS) weinig kans maakt om pi-hole te omzeilen. Het, ondertussen verplaatste, document vind je hier.

Gebruikers die een niet compatibele firewall hebben, blijven echter in de kou staan. Er werd een sectie toegevoegd om een pi-hole lijst te genereren, twijfelachtig of dit veel gebruikt wordt.

Voor de gebruikers van unbound (of bind, knot resolver - niet getest) heb ik een oplossing uitgewerkt die bescherming moet bieden tegen DoH. In unbound 1.14.0 (release notes hier) is de ondersteuning voor response policy zones flink uitgebreid (was al ondersteund vanaf v1.10 (lees hier)

Meer details vind je in deze manual. Zelf maak ik gebruik van een aparte config file (/etc/unbound/unbound.conf.d/rpz.conf), met daarin de rpz gerelateerde settings). Lees zeker de waarschuwing over module-config (slechts één entry in alle config files, laatste wordt actief).

- De test werd initieel gestart met de urlhaus rpz (malware). Deze zone wordt alle 5 minuten geupdate. Deze test loopt reeds een maand zonder enig probleem.
- De test met de DoH zone loopt nu een week, geen problemen, maar de IP's worden al veel langer geblocked (op de firewall), hier verwacht ik dus ook geen problemen.
- De DoH rpz file vind je hier (dagelijkse update).

Er zijn voordelen en nadelen verbonden aan het gebruik van response policy zones, een aantal ervan zijn opgelijst in sectie 4 ( Pro-Con using response policy zones). Het belangrijkste voordeel lijkt mij dat unbound de zone info automatisch update, gebaseerd op de SOA informatie in het bestand.

Zoals altijd:
- het staat iedereen vrij te doen wat hij/zij wil, gebruik het ... of niet.
- al mijn documenten zijn PDF, géén vertrouwen in PDF -> niet openen.
- getest met laatst pi-hole versie en laatste unbound versie (1.14.0). Werkt het niet -> upgrade...
- issues hier.

[Videopac]

nero355 schreef op vrijdag 31 december 2021 @ 15:46:

[...]

Haal die eens weg, want die laat heel veel rommel toe onder het motto "Gebruiksvriendelijkheid"

[...]

Lijsten zijn toch complementair aan elkaar?
Verder sta ik open voor goede bloklijsten, niet alleen voor advertenties en tracking maar ook inhoudelijk zoals malware, phising, extreem geweld, gokken, mijnen, misleiding etc.

[dss58]

Videopac schreef op zondag 2 januari 2022 @ 23:12:
[...]

Lijsten zijn toch complementair aan elkaar?
Verder sta ik open voor goede bloklijsten, niet alleen voor advertenties en tracking maar ook inhoudelijk zoals malware, phising, extreem geweld, gokken, mijnen, misleiding etc.

kijk hier maar is
https://firebog.net/

[W1ck1e]

dss58 schreef op zondag 2 januari 2022 @ 23:14:
[...]

kijk hier maar is
https://firebog.net/

Ik heb er maar EENS gekeken.
Dat IS inderdaad een mooie pagina.
(dank je wel )

[sweetdude]

dss58 schreef op zondag 2 januari 2022 @ 23:14:
[...]

kijk hier maar is
https://firebog.net/

hoeveel van die lijsten zijn al niet in de veel gebruikte dbl.oisd.nl opgenomen?

[dss58]

sweetdude schreef op maandag 3 januari 2022 @ 14:39:
[...]


hoeveel van die lijsten zijn al niet in de veel gebruikte dbl.oisd.nl opgenomen?

zoekt en gij zult vinden https://oisd.nl/includedlists
maar is in wezen niet belangrijk, met pihole -g filtert ie de dubbele en ongeldige toch uit.

[deHakkelaar]

nero355 schreef op zondag 2 januari 2022 @ 16:08:
Dan wordt het tijd om eindelijk /etc/dhcpcd.conf te slopen en terug te gaan naar /etc/network/interfaces zoals we altijd al deden!

Hebben we het geloof ik zelfs een paar keer over gehad in dit topic...

Ik kwam er net achter dat Pi-hole tegenwoordig niet meer afhankelijk lijkt te zijn van dhcpcd5 (wordt niet meer geinstalleerd):

pi@ph5b:~ $ curl -sSL https://install.pi-hole.net | grep -i dhcpcd5
pi@ph5b:~ $

Tov de iputils-ping package waar Pi-hole nog wel van afhankelijk is:

pi@ph5b:~ $ curl -sSL https://install.pi-hole.net | grep -i iputils-ping
        PIHOLE_DEPS=(cron curl iputils-ping lsof psmisc sudo unzip idn2 sqlite3 libcap2-bin dns-root-data libcap2)

Dus is de kans groot dat je plannetje nu wel werkt met alleen /etc/network/interfaces en ifupdown

pi@ph5b:~ $ dpkg -S '/etc/network/interfaces*'
ifupdown: /etc/network/interfaces.d

[deHakkelaar]

Koepert schreef op zondag 2 januari 2022 @ 22:23:
Kut. Ik heb unbound om zeep (failed met een restart to quickly error).

code:

journalctl -u unbound

[Koepert]

deHakkelaar schreef op maandag 3 januari 2022 @ 16:33:
[...]

code:

journalctl -u unbound

Eerste snippet:

code:

Jan 02 20:32:22 Pi-Hole package-helper[272]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown 
Jan 02 20:32:22 Pi-Hole package-helper[272]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':
Jan 02 20:32:22 Pi-Hole package-helper[272]: read /etc/unbound/unbound.conf failed: 2 errors in configur
Jan 02 20:32:22 Pi-Hole package-helper[307]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown 
Jan 02 20:32:22 Pi-Hole package-helper[307]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':
Jan 02 20:32:22 Pi-Hole package-helper[307]: read /etc/unbound/unbound.conf failed: 2 errors in configur
Jan 02 20:32:22 Pi-Hole unbound[310]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown keyword
Jan 02 20:32:22 Pi-Hole unbound[310]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':'
Jan 02 20:32:22 Pi-Hole unbound[310]: read /etc/unbound/unbound.conf failed: 2 errors in configuration f
Jan 02 20:32:22 Pi-Hole unbound[310]: [1641151942] unbound[310:0] fatal error: Could not read config fil
Jan 02 20:32:22 Pi-Hole systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE
Jan 02 20:32:22 Pi-Hole systemd[1]: unbound.service: Failed with result 'exit-code'.
Jan 02 20:32:22 Pi-Hole systemd[1]: Failed to start Unbound DNS server.
Jan 02 20:32:23 Pi-Hole systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restar
Jan 02 20:32:23 Pi-Hole systemd[1]: unbound.service: Scheduled restart job, restart counter is at 1.
Jan 02 20:32:23 Pi-Hole systemd[1]: Stopped Unbound DNS server.
Jan 02 20:32:23 Pi-Hole systemd[1]: Starting Unbound DNS server...
Jan 02 20:32:23 Pi-Hole package-helper[367]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown 
Jan 02 20:32:23 Pi-Hole package-helper[367]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':
Jan 02 20:32:23 Pi-Hole package-helper[367]: read /etc/unbound/unbound.conf failed: 2 errors in configur
Jan 02 20:32:23 Pi-Hole package-helper[370]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown 
Jan 02 20:32:23 Pi-Hole package-helper[370]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':
Jan 02 20:32:23 Pi-Hole package-helper[370]: read /etc/unbound/unbound.conf failed: 2 errors in configur
Jan 02 20:32:23 Pi-Hole unbound[373]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown keyword
Jan 02 20:32:23 Pi-Hole unbound[373]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':'

Tweede snippet

code:

Jan 02 21:56:10 Pi-Hole systemd[1]: Starting Unbound DNS server...
Jan 02 21:56:10 Pi-Hole package-helper[6411]: /var/lib/unbound/root.key has content
Jan 02 21:56:10 Pi-Hole package-helper[6411]: success: the anchor is ok
Jan 02 21:56:10 Pi-Hole unbound[6415]: [1641156970] unbound[6415:0] error: can't bind socket: Address al
Jan 02 21:56:10 Pi-Hole unbound[6415]: [1641156970] unbound[6415:0] fatal error: could not open ports
Jan 02 21:56:10 Pi-Hole systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE
Jan 02 21:56:10 Pi-Hole systemd[1]: unbound.service: Failed with result 'exit-code'.
Jan 02 21:56:10 Pi-Hole systemd[1]: Failed to start Unbound DNS server.
Jan 02 21:56:10 Pi-Hole systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restar
Jan 02 21:56:10 Pi-Hole systemd[1]: unbound.service: Scheduled restart job, restart counter is at 4.
Jan 02 21:56:10 Pi-Hole systemd[1]: Stopped Unbound DNS server.
Jan 02 21:56:10 Pi-Hole systemd[1]: Starting Unbound DNS server...
Jan 02 21:56:10 Pi-Hole package-helper[6419]: /var/lib/unbound/root.key has content
Jan 02 21:56:10 Pi-Hole package-helper[6419]: success: the anchor is ok
Jan 02 21:56:10 Pi-Hole unbound[6423]: [1641156970] unbound[6423:0] error: can't bind socket: Address al
Jan 02 21:56:10 Pi-Hole unbound[6423]: [1641156970] unbound[6423:0] fatal error: could not open ports
Jan 02 21:56:10 Pi-Hole systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE
Jan 02 21:56:10 Pi-Hole systemd[1]: unbound.service: Failed with result 'exit-code'.
Jan 02 21:56:10 Pi-Hole systemd[1]: Failed to start Unbound DNS server.
Jan 02 21:56:11 Pi-Hole systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restar
Jan 02 21:56:11 Pi-Hole systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5.
Jan 02 21:56:11 Pi-Hole systemd[1]: Stopped Unbound DNS server.
Jan 02 21:56:11 Pi-Hole systemd[1]: unbound.service: Start request repeated too quickly.
Jan 02 21:56:11 Pi-Hole systemd[1]: unbound.service: Failed with result 'exit-code'.
Jan 02 21:56:11 Pi-Hole systemd[1]: Failed to start Unbound DNS server.

[deHakkelaar]

Koepert schreef op maandag 3 januari 2022 @ 16:38:
Jan 02 21:56:10 Pi-Hole unbound[6423]: [1641156970] unbound[6423:0] error: can't bind socket: Address allready in use

Bovenstaande geeft aan dat unbound niet kan opstarten vanwege een socket (IP + poort) conflict.
Onderstaande geeft aan welke TCP en UDP sockets nu bezet zijn door bepaalde processen:

code:

sudo netstat -nltup

Als unbound niet wil opstarten, check dan of de poort wel goed gedefinieerd staat en niet conflicteert met de huidige processen (EDIT: de officiele gids configureert poort 5335):

code:

grep port -R /etc/unbound/unbound.conf*

[ Voor 5% gewijzigd door deHakkelaar op 03-01-2022 17:18 . Reden: boel dddddtttdt ]

[deHakkelaar]

Koepert schreef op maandag 3 januari 2022 @ 16:38:

code:

Jan 02 20:32:22 Pi-Hole package-helper[272]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown 
Jan 02 20:32:22 Pi-Hole package-helper[272]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':
Jan 02 20:32:22 Pi-Hole package-helper[272]: read /etc/unbound/unbound.conf failed: 2 errors in configur
Jan 02 20:32:22 Pi-Hole package-helper[307]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown 
Jan 02 20:32:22 Pi-Hole package-helper[307]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':
Jan 02 20:32:22 Pi-Hole package-helper[307]: read /etc/unbound/unbound.conf failed: 2 errors in configur
Jan 02 20:32:22 Pi-Hole unbound[310]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: unknown keyword
Jan 02 20:32:22 Pi-Hole unbound[310]: /etc/unbound/unbound.conf.d/pi-hole.conf:1: error: stray ':'
Jan 02 20:32:22 Pi-Hole unbound[310]: read /etc/unbound/unbound.conf failed: 2 errors in configuration f
Jan 02 20:32:22 Pi-Hole unbound[310]: [1641151942] unbound[310:0] fatal error: Could not read config fil

code:

unbound-checkconf

[Koepert]

deHakkelaar schreef op maandag 3 januari 2022 @ 16:56:
[...]

Bovenstaande geeft aan dat unbound niet kan opstarten vanwege een socket (IP + poort) conflict.
Onderstaande geeft aan welke TCP en UDP sockets nu bezet zijn door bepaalde processen:

code:

sudo netstat -nltup

Als unbound niet wil opstarten, check dan of de poort wel goed gedefinieerd staat en niet conflicteert met de huidige processen (EDIT: de officiele gids configureert poort 5335):

code:

grep port -R /etc/unbound/unbound.conf*

Die laatste geeft dit terug:

code:

/etc/unbound/unbound.conf.d/pi-hole.conf:    port: 5335

[deHakkelaar]

@Koepert , maar heb je een conflict?

deHakkelaar schreef op maandag 3 januari 2022 @ 16:56:
Onderstaande geeft aan welke TCP en UDP sockets nu bezet zijn door bepaalde processen:

code:

sudo netstat -nltup

[Koepert]

deHakkelaar schreef op maandag 3 januari 2022 @ 17:48:
@Koepert , maar heb je een conflict?

[...]

Dat weet ik nog niet, want ook geen Netstat in de VM (of de host)

[deHakkelaar]

Koepert schreef op maandag 3 januari 2022 @ 17:53:
Dat weet ik nog niet, want ook geen Netstat in de VM (of de host)

pi@ph5b:~ $ dpkg -S /bin/netstat
net-tools: /bin/netstat

Zit in:

code:

sudo apt install net-tools

En kun je ook onderstaande hier plaatsen aub?
Mogelijk een foutje ergens.

code:

sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*

[ Voor 27% gewijzigd door deHakkelaar op 03-01-2022 17:59 ]

[Koepert]

deHakkelaar schreef op maandag 3 januari 2022 @ 17:58:
[...]

pi@ph5b:~ $ dpkg -S /bin/netstat
net-tools: /bin/netstat

Zit in:

code:

sudo apt install net-tools

En kun je ook onderstaande hier plaatsen aub?
Mogelijk een foutje ergens.

code:

sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*

NETSTAT

code:

sudo netstat -nltup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      32329/pihole-FTL    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      374/lighttpd        
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      32329/pihole-FTL    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      298/sshd            
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      518/master          
tcp6       0      0 ::1:4711                :::*                    LISTEN      32329/pihole-FTL    
tcp6       0      0 :::80                   :::*                    LISTEN      374/lighttpd        
tcp6       0      0 :::53                   :::*                    LISTEN      32329/pihole-FTL    
tcp6       0      0 :::22                   :::*                    LISTEN      298/sshd            
tcp6       0      0 ::1:25                  :::*                    LISTEN      518/master          
udp        0      0 0.0.0.0:53              0.0.0.0:*                           32329/pihole-FTL    
udp        0      0 0.0.0.0:68              0.0.0.0:*                           110/dhcpcd          
udp6       0      0 :::53                   :::*                                32329/pihole-FTL

Grep

code:

sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:    verbosity: 0
/etc/unbound/unbound.conf.d/pi-hole.conf:    interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf:    port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    root-hints: "/var/lib/unbound/root.hints"
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf:    so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: x.x.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: x.x.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: x.x.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 10.0.0.0/8

[deHakkelaar]

Koepert schreef op maandag 3 januari 2022 @ 18:02:

code:

sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*

Je mist een heel belangrijk bestandje:

pi@ph5b:~ $ sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*
/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
[..]

Onderstaande hersteld dat bestandje:

code:

sudo tee /etc/unbound/unbound.conf <<< 'include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"'

Opnieuw herstarten:

code:

sudo service unbound restart

En journals controleren:

code:

journalctl -u unbound

[Koepert]

deHakkelaar schreef op maandag 3 januari 2022 @ 18:09:
[...]

Je mist een heel belangrijk bestandje:

pi@ph5b:~ $ sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*
/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
[..]

Onderstaande hersteld dat bestandje:

code:

sudo tee /etc/unbound/unbound.conf <<< 'include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"'

Opnieuw herstarten:

code:

sudo service unbound restart

En journals controleren:

code:

journalctl -u unbound

Ergens iets mis gegaan in de kopie denk ik..

code:

Jan 03 18:17:11 Pi-Hole package-helper[4973]: read /etc/unbound/unbound.conf failed: 5 errors in configurat
Jan 03 18:17:11 Pi-Hole unbound[4976]: /etc/unbound/unbound.conf:1: error: unknown keyword 'include-topleve
Jan 03 18:17:11 Pi-Hole unbound[4976]: /etc/unbound/unbound.conf:1: error: stray ':'
Jan 03 18:17:11 Pi-Hole unbound[4976]: /etc/unbound/unbound.conf:1: error: stray '"'
Jan 03 18:17:11 Pi-Hole unbound[4976]: /etc/unbound/unbound.conf:1: error: unknown keyword '/etc/unbound/un
Jan 03 18:17:11 Pi-Hole unbound[4976]: /etc/unbound/unbound.conf:1: error: stray '"'
Jan 03 18:17:11 Pi-Hole unbound[4976]: read /etc/unbound/unbound.conf failed: 5 errors in configuration fil
Jan 03 18:17:11 Pi-Hole unbound[4976]: [1641230231] unbound[4976:0] fatal error: Could not read config file
Jan 03 18:17:11 Pi-Hole systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE
Jan 03 18:17:11 Pi-Hole systemd[1]: unbound.service: Failed with result 'exit-code'.
Jan 03 18:17:11 Pi-Hole systemd[1]: Failed to start Unbound DNS server.
Jan 03 18:17:11 Pi-Hole systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restart.
Jan 03 18:17:11 Pi-Hole systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5.
Jan 03 18:17:11 Pi-Hole systemd[1]: Stopped Unbound DNS server.
Jan 03 18:17:11 Pi-Hole systemd[1]: unbound.service: Start request repeated too quickly.
Jan 03 18:17:11 Pi-Hole systemd[1]: unbound.service: Failed with result 'exit-code'.
Jan 03 18:17:11 Pi-Hole systemd[1]: Failed to start Unbound DNS server.

[deHakkelaar]

@Koepert , er klopt wel meer niet met een aantal zaken:

pi@ph5b:~ $ sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*
/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:    auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:    verbosity: 0
/etc/unbound/unbound.conf.d/pi-hole.conf:    interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf:    port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    edns-buffer-size: 1472
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf:    so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fe80::/10

Als ik jouw was zou ik opnieuw beginnen:

code:

sudo apt purge unbound

code:

sudo rm -r /etc/unbound/*

En de gids goed volgen (EDIT: Zonder iets extras te doen met de root.hints! ):
https://docs.pi-hole.net/guides/dns/unbound/

EDIT2: Ow en niet vergeten onderstaande om af te ronden:
deHakkelaar in "Raspberry Pi - deel 2"

[ Voor 3% gewijzigd door deHakkelaar op 03-01-2022 18:25 ]

[Koepert]

deHakkelaar schreef op maandag 3 januari 2022 @ 18:22:
@Koepert , er klopt wel meer niet met een aantal zaken:

pi@ph5b:~ $ sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*
/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:    auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:    verbosity: 0
/etc/unbound/unbound.conf.d/pi-hole.conf:    interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf:    port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    edns-buffer-size: 1472
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf:    so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fe80::/10

Als ik jouw was zou ik opnieuw beginnen:

code:

sudo apt purge unbound

code:

sudo rm -r /etc/unbound/*

En de gids goed volgen (EDIT: Zonder iets extras te doen met de root.hints! ):
https://docs.pi-hole.net/guides/dns/unbound/

Denk dat dat wel n goed idee is ja

Geen idee waar t door veroorzaakt is echter.. nu lijkt het wel te werken

In de gids staan echter 2 dingen, waar ik online conflicterende dingen over lees zijn:

You should also consider adding

edns-packet-max=1232

to a config file like /etc/dnsmasq.d/99-edns.conf to signal FTL to adhere to this limit.

Heb ik vorige keer NIET gedaan.


En 2

If you are installing unbound from a package manager, it should install the root.hints file automatically with the dependency dns-root-data. The root hints will then be automatically updated by your package manager.

Optional: Download the current root hints file (the list of primary root servers which are serving the domain "." - the root domain). Update it roughly every six months. Note that this file changes infrequently. This is only necessary if you are not installing unbound from a package manager. If you do this optional step, you will need to uncomment the root-hints: configuration line in the suggested config file.

Die had ik NIET extra gedownload. maar bleek ook niet aanwezig en daarmee problemen te veroorzaken.

Net als (eigenlijk dus 3)

Disable resolvconf for unbound (optional)¶

The unbound package can come with a systemd service called unbound-resolvconf.service and default enabled. It instructs resolvconf to write unbound's own DNS service at nameserver 127.0.0.1 , but without the 5335 port, into the file /etc/resolv.conf. That /etc/resolv.conf file is used by local services/processes to determine DNS servers configured. If you configured /etc/dhcpcd.conf with a static domain_name_servers= line, these DNS server(s) will be ignored/overruled by this service.

To check if this service is enabled for your distribution, run below one and take note of the Active line. It will show either active or inactive or it might not even be installed resulting in a could not be found message:

sudo systemctl status unbound-resolvconf.service

To disable the service if so desire, run below two:

sudo systemctl disable unbound-resolvconf.service

sudo systemctl stop unbound-resolvconf.service

To have the domain_name_servers= in the file /etc/dhcpcd.conf activated/propagate, run below one:

sudo systemctl restart dhcpcd

And check with below one if IP(s) on the nameserver line(s) reflects the ones in the /etc/dhcpcd.conf file:

cat /etc/resolv.conf

Maar goed. Ik heb op dit moment ook Nginx vervangen voor Traefik en die schijnt weer niet lekker te gaan met local DNS..dus ik moet nog maar ff overwegen of ik pihole niet via Cloudflare laat lopen (zoals nu).

Thx voor de hulp iig.. Nog steeds zijn dit mn top 2 blocked domains trouwens (Weet je nog, waar t mee begon )

code:

lb._dns-sd._udp.0.178.168.192.in-addr.arpa
lb._dns-sd._udp.fritz.box

[deHakkelaar]

Koepert schreef op maandag 3 januari 2022 @ 18:32:
In de gids staan echter 2 dingen, waar ik online conflicterende dingen over lees zijn:

[...]

Heb ik vorige keer NIET gedaan.

Ik heb die edns-packet-max configuratie niet en alles draait als een zonnetje.
Ik vermoed dat dat een oplossing is om verkeer door een VPN tunnel te jagen waar je meestal niet de volledig MTU size van 1500 ter beschikking hebt.
Dus als je geen VPN server of iets dergelijks draait of enige andere problemen ondervind zou ik die stap niet doen.

Koepert schreef op maandag 3 januari 2022 @ 18:32:
En 2

[...]

Die had ik NIET extra gedownload. maar bleek ook niet aanwezig en daarmee problemen te veroorzaken.

De root.hints worden automatisch meegeinstalleerd met unbound en verder hoef je niks extras te doen:

pi@ph5b:~ $ apt depends unbound
unbound
  Depends: adduser
  Depends: dns-root-data
[..]

pi@ph5b:~ $ apt policy dns-root-data
dns-root-data:
  Installed: 2021011101

pi@ph5b:~ $ dpkg -L dns-root-data
[..]
/usr/share/dns/root.hints
/usr/share/dns/root.hints.sig
[..]

Koepert schreef op maandag 3 januari 2022 @ 18:32:
Net als (eigenlijk dus 3)

Die stap zit ook in onderstaande welke ik eerder plaatste:
deHakkelaar in "Raspberry Pi - deel 2"

Koepert schreef op maandag 3 januari 2022 @ 18:32:
Thx voor de hulp iig.. Nog steeds zijn dit mn top 2 blocked domains trouwens (Weet je nog, waar t mee begon )

code:

lb._dns-sd._udp.0.178.168.192.in-addr.arpa
lb._dns-sd._udp.fritz.box

deHakkelaar schreef op zondag 2 januari 2022 @ 14:19:
Kijk ofdat je probleem verdwijnt als je ook het "local domain" configureerd in de conditional forwarding instellingen?
Zonder dit "local domain" probeert pihole-FTL vermoedelijk bovenstaande zelf op te lossen ipv te forwarden naar je router IP.

EDIT: Ow en ik zou de logs in de gaten houden ipv de data op de web GUI!
De logs geven iets meer details.
Je kunt de logs live volgen met onderstaande:

code:

pihole -t

Of met less door de logs browsen:

code:

less /var/log/pihole.log

[Koepert]

Oh ja sorry, die stappen van jou had ik wel gezet, dus 3 vervalt

(en CF staat idd weer AAN, MET domain gevuld) sindsdien loopt - lb._dns-sd._udp.fritz.box hard in .. zal de logs eens monitoren

[ Voor 8% gewijzigd door Koepert op 03-01-2022 19:05 ]

[dss58]

deHakkelaar schreef op maandag 3 januari 2022 @ 18:59:
[...]

Ik heb die edns-packet-max configuratie niet en alles draait als een zonnetje.
Ik vermoed dat dat een oplossing is om verkeer door een VPN tunnel te jagen waar je meestal niet de volledig MTU size van 1500 ter beschikking hebt.
Dus als je geen VPN server of iets dergelijks draait of enige andere problemen ondervind zou ik die stap niet doen.

[...]

heb ik dus wel gedaan terwijl ik geen problemen ondervond, kreeg in het dashboard links naast de hostname een gele driehoek te zien met een uitroepteken erin en daarna was het weg, en ik vond deze oplossing op discourse, maar vraag me niet wat het in houd

[deHakkelaar]

@dss58 , geen idee waarom maar dit zegt de man page:

pi@ph5a:~ $ man dnsmasq
[..]
       -P, --edns-packet-max=<size>
              Specify the largest EDNS.0 UDP packet which is supported  by  the  DNS
              forwarder. Defaults to 4096, which is the RFC5625-recommended size.

Veel nieuwe routers en ook pihole-FTL kunnen omgaan met EDNS data dus daar zal het wel een rol spelen.

[deHakkelaar]

Aha stond voor m'n neus:
Wikipedia: Extension Mechanisms for DNS

[dss58]

deHakkelaar schreef op maandag 3 januari 2022 @ 19:31:
@dss58 , geen idee waarom maar dit zegt de man page:

pi@ph5a:~ $ man dnsmasq
[..]
       -P, --edns-packet-max=<size>
              Specify the largest EDNS.0 UDP packet which is supported  by  the  DNS
              forwarder. Defaults to 4096, which is the RFC5625-recommended size.

Veel nieuwe routers en ook pihole-FTL kunnen omgaan met EDNS data dus daar zal het wel een rol spelen.

ik heb een fritzbox 7583, 2 jaar oud geloof ik, en raspi OS en pihole zijn beide uiteraard up to date, tnx voor de info !
edit: ik heb geen VPN

[Koepert]

deHakkelaar schreef op maandag 3 januari 2022 @ 18:59:

[...]

Die stap zit ook in onderstaande welke ik eerder plaatste:
deHakkelaar in "Raspberry Pi - deel 2"

[...]


[...]

Ik heb even in de logs gekeken en zie erg vaak dit rijtje voorkomen (ook met de variant met IP van Iphone van de vrouw)

Jan  3 04:58:26 dnsmasq[918]: query[PTR] lb._dns-sd._udp.0.178.168.192.in-addr.arpa from 192.168.178.80
Jan  3 04:58:26 dnsmasq[918]: forwarded lb._dns-sd._udp.0.178.168.192.in-addr.arpa to 192.168.178.1
Jan  3 04:58:26 dnsmasq[918]: query[PTR] lb._dns-sd._udp.fritz.box from 192.168.178.80
Jan  3 04:58:26 dnsmasq[918]: forwarded lb._dns-sd._udp.fritz.box to 192.168.178.1
Jan  3 04:58:26 dnsmasq[918]: reply lb._dns-sd._udp.0.178.168.192.in-addr.arpa is NXDOMAIN
Jan  3 04:58:26 dnsmasq[918]: reply lb._dns-sd._udp.fritz.box is NXDOMAIN
Jan  3 04:58:26 dnsmasq[918]: reply lb._dns-sd._udp.143.42.72.100.in-addr.arpa is NXDOMAIN

[deHakkelaar]

@Koepert :

Concerning Pi-hole, everything is fine in this screenshot. You iPhone is making the query to lb_dns-sd._udp.fritz.box. Pi-hole doesn't know the answer and forwards to to the Fritzbox. This replies with NXDOMAIN and requests Pi-hole should not cache this Blocked (extern, NXRA).

https://discourse.pi-hole...hlreich-geblockt/42312/34

[ Voor 61% gewijzigd door deHakkelaar op 03-01-2022 23:41 ]

[nero355]

Koepert schreef op maandag 3 januari 2022 @ 17:53:
Dat weet ik nog niet, want ook geen Netstat in de VM (of de host)

Ik kreeg dit onlangs te horen : Anoniem: 30722 in "Het grote IPv6 topic"

Dus dan maar :

# ss --help

Usage: ss [ OPTIONS ]
       ss [ OPTIONS ] [ FILTER ]
   -h, --help          this message
   -V, --version       output version information
   -n, --numeric       don't resolve service names
   -r, --resolve       resolve host names
   -a, --all           display all sockets
   -l, --listening     display listening sockets
   -o, --options       show timer information
   -e, --extended      show detailed socket information
   -m, --memory        show socket memory usage
   -p, --processes     show process using socket
   -i, --info          show internal TCP information
       --tipcinfo      show internal tipc socket information
   -s, --summary       show socket usage summary
       --tos           show tos and priority information
   -b, --bpf           show bpf filter socket information
   -E, --events        continually display sockets as they are destroyed
   -Z, --context       display process SELinux security contexts
   -z, --contexts      display process and socket SELinux security contexts
   -N, --net           switch to the specified network namespace name

   -4, --ipv4          display only IP version 4 sockets
   -6, --ipv6          display only IP version 6 sockets
   -0, --packet        display PACKET sockets
   -t, --tcp           display only TCP sockets
   -S, --sctp          display only SCTP sockets
   -u, --udp           display only UDP sockets
   -d, --dccp          display only DCCP sockets
   -w, --raw           display only RAW sockets
   -x, --unix          display only Unix domain sockets
       --tipc          display only TIPC sockets
       --vsock         display only vsock sockets
   -f, --family=FAMILY display sockets of type FAMILY
       FAMILY := {inet|inet6|link|unix|netlink|vsock|tipc|xdp|help}

   -K, --kill          forcibly close sockets, display what was closed
   -H, --no-header     Suppress header line
   -O, --oneline       socket's data printed on a single line

   -A, --query=QUERY, --socket=QUERY
       QUERY := {all|inet|tcp|udp|raw|unix|unix_dgram|unix_stream|unix_seqpacket|packet|netlink|vsock_stream|vsock_dgram|tipc}[,QUERY]

   -D, --diag=FILE     Dump raw information about TCP sockets to FILE
   -F, --filter=FILE   read filter information from FILE
       FILTER := [ state STATE-FILTER ] [ EXPRESSION ]
       STATE-FILTER := {all|connected|synchronized|bucket|big|TCP-STATES}
         TCP-STATES := {established|syn-sent|syn-recv|fin-wait-{1,2}|time-wait|closed|close-wait|last-ack|listening|closing}
          connected := {established|syn-sent|syn-recv|fin-wait-{1,2}|time-wait|close-wait|last-ack|closing}
       synchronized := {established|syn-recv|fin-wait-{1,2}|time-wait|close-wait|last-ack|closing}
             bucket := {syn-recv|time-wait}
                big := {established|syn-sent|fin-wait-{1,2}|closed|close-wait|last-ack|listening|closing}

gebruiken!

deHakkelaar schreef op maandag 3 januari 2022 @ 17:58:

pi@ph5b:~ $ dpkg -S /bin/netstat
net-tools: /bin/netstat

Zit in:

code:

sudo apt install net-tools

Dat is dus blijkbaar niet meer hip!

[deHakkelaar]

@nero355 , netstat is depreciated.
Maar ik vind de output beter leesbaar als ss of sudo lsof -i

pi@ph5b:~ $ dpkg -S /bin/ss
iproute2: /bin/ss

pi@ph5b:~ $ dpkg -S /usr/bin/lsof
lsof: /usr/bin/lsof

EDIT: Ow en er zitten nog een boel legacy tools in voor backwards compatibility:

pi@ph5b:~ $ dpkg -L net-tools
/.
/bin
/bin/netstat
/sbin
/sbin/ifconfig
/sbin/ipmaddr
/sbin/iptunnel
/sbin/mii-tool
/sbin/nameif
/sbin/plipconfig
/sbin/rarp
/sbin/route
/sbin/slattach
/usr
/usr/sbin
/usr/sbin/arp
[..]

[ Voor 39% gewijzigd door deHakkelaar op 04-01-2022 20:29 ]

[Anoniem: 211516]

dns service not running, heb ik iets gemist ?

[mithras]

Anoniem: 211516 schreef op dinsdag 4 januari 2022 @ 23:22:
dns service not running, heb ik iets gemist ?

Ik was gisteren met installatie gravity sync bezig en kreeg hetzelfde. Dacht dat het aan mij lag maar zie jou reactie en is een bekend issue op Github: 734.

Er wordt gekeken naar een lange termijn fix maar voorlopig lijkt deze reactie op het forum te werken: een environment variabele toevoegen DNSMASQ_USER=root.

Zelf net getest en krijg weer allemaal groene lampjes

[Anoniem: 211516]

mithras schreef op woensdag 5 januari 2022 @ 14:13:
[...]
Ik was gisteren met installatie gravity sync bezig en kreeg hetzelfde. Dacht dat het aan mij lag maar zie jou reactie en is een bekend issue op Github: 734.

Er wordt gekeken naar een lange termijn fix maar voorlopig lijkt deze reactie op het forum te werken: een environment variabele toevoegen DNSMASQ_USER=root.

Zelf net getest en krijg weer allemaal groene lampjes

Ja las het.

[Dracula]

Als ik Use Conditional Forwarding aan heb staan op mijn Pi en hier netjes het IP van mijn router en local domain naam heb opgegeven die ook in mijn unifi USP staat waar cached de Pi dan de DNS records?

Ik heb een device een andere naam gegeven en in de ubiquiti USP het oude record verwijderd uit /etc/hosts maar de PI ziet het device nog steeds met zijn oude hostname staan in de clients list.

Ik wil dit graag updaten / verwijderen omdat er wat rare dingen gebeuren met dit device en ik zeker wil weten dat er nergens een "kink" in de kabel zit.

[nero355]

@Dracula
En je weet zeker dat de USG het apparaat ook niet meer onder de oude naam resolved

Je zou dit eens kunnen proberen : https://discourse.pi-hole...ush-my-pi-hole-cache/3020

[Dracula]

nero355 schreef op woensdag 5 januari 2022 @ 16:03:
@Dracula
En je weet zeker dat de USG het apparaat ook niet meer onder de oude naam resolved

Je zou dit eens kunnen proberen : https://discourse.pi-hole...ush-my-pi-hole-cache/3020

Mijn host file op de USG laat geen device zien met de naam die het zou moeten zijn en dat IP.

Ja die cache flush zag ik ook alleen die flushed letterlijk alle opgebouwde cache zo te zien. Daarnaast hangt er ook nog Unbound bij in de config geen idee of dat nog uit maakt....

Daarnaast is het herstarten van de dns service hetzelfde als herstarten van de PI lijkt mij.

Raar gedoe

[ Voor 8% gewijzigd door Dracula op 05-01-2022 16:24 ]

[nero355]

Dracula schreef op woensdag 5 januari 2022 @ 16:17:
Mijn host file op de USG laat geen device zien met de naam die het zou moeten zijn en dat IP.

Maar wat doet een nslookup of dig richting zowel je Pi-Hole als je USG zien

Voor voorbeelden zie de vele reacties van @deHakkelaar

[deHakkelaar]

mithras schreef op woensdag 5 januari 2022 @ 14:13:
environment variabele toevoegen DNSMASQ_USER=root.

Heb je wel onderstaande Linux capability gedefinieerd voor je container?

code:

   cap_add:
       - NET_ADMIN

https://github.com/pi-hole/docker-pi-hole

pi@ph5b:~ $ man capabilities
[..]
DESCRIPTION
       For  the  purpose of performing permission checks, traditional UNIX im‐
       plementations distinguish two categories of processes: privileged  pro‐
       cesses  (whose  effective  user  ID  is  0, referred to as superuser or
       root), and unprivileged processes (whose  effective  UID  is  nonzero).
       Privileged processes bypass all kernel permission checks, while unpriv‐
       ileged processes are subject to full permission checking based  on  the
       process's  credentials (usually: effective UID, effective GID, and sup‐
       plementary group list).

       Starting with kernel 2.2, Linux divides  the  privileges  traditionally
       associated  with  superuser into distinct units, known as capabilities,
       which can be independently enabled and disabled.   Capabilities  are  a
       per-thread attribute.
[..]
       CAP_NET_ADMIN
              Perform various network-related operations:
              * interface configuration;
              * administration of IP firewall, masquerading, and accounting;
              * modify routing tables;
              * bind to any address for transparent proxying;
              * set type-of-service (TOS);
              * clear driver statistics;
              * set promiscuous mode;
              * enabling multicasting;
              * use setsockopt(2) to set the following socket options:  SO_DE‐
                BUG,  SO_MARK, SO_PRIORITY (for a priority outside the range 0
                to 6), SO_RCVBUFFORCE, and SO_SNDBUFFORCE.

Met de juiste caps zou DNSMASQ_USER=pihole ook gewoon moeten werken.

[deHakkelaar]

dss58 schreef op maandag 3 januari 2022 @ 19:38:
[...]

ik heb een fritzbox 7583, 2 jaar oud geloof ik, en raspi OS en pihole zijn beide uiteraard up to date, tnx voor de info !
edit: ik heb geen VPN

Ik zag onderstaande draadje met boel info voorbij komen wbt edns-packet-max= :
https://discourse.pi-hole...t-size-meldungen/51910/18
Ik snap alleen niet waarom pihole-FTL geconfigureerd zou moeten worden met edns-packet-max=1472.
De pihole-FTL daemon communiceerd met unbound over de loopback interface lo en daar is de MTU size belachelijk groot (voordat fragmentatie optreed over TCP ingeval dat een enkele UDP packet niet volstaat vanwege afmeting):

pi@ph5b:~ $ ip link show lo
1: lo: ... mtu 65536

Tov van de MTU van de eth0 interface welke weer gebruikt wordt door unbound om upstream servers te benaderen:

pi@ph5b:~ $ ip link show eth0
2: eth0: ... mtu 1500

Zal wel iets weer niet snappen

[TheCeet]

Hup. Weer een nieuwe update!

Pi-hole FTL v5.13, Web v5.10 and Core v5.8 released
https://pi-hole.net/2022/...0-and-core-v5-8-released/

[deHakkelaar]

@dss58 , Ter info:
https://www.cloudflare.co...etwork-layer/what-is-mtu/

Met DNS worden packet's verzoekjes/antwoorden ook gefragmenteerd als ze niet in een enkele UDP packet passen en gaat dan over op TCP ipv UDP omdat met TCP het makkelijker is om de oorspronkelijke data weer te defragmenteren/reconstrueren.
UDP is "stateless" omdat deze geen handshake kent zoals bij TCP wel het geval is.
Met UDP worden packets gewoon de pijp in gejaagd zonder dat de zender weet ofdat ze aangekomen zijn.
Bij TCP komen packets sequentieel aan vanwege dit handshake-en.
Met UDP kan het gebeuren dat twee packets net even een andere route volgen op het internet waardoor packet1 later kan binnenkomen als packet2, die toch later is verzonden, wat weer moeilijker is om te reconstrueren.
Pew ...

[ Voor 3% gewijzigd door deHakkelaar op 05-01-2022 20:20 ]