[Pi-Hole] Ervaringen & discussie

[j1nx]

meesje schreef op woensdag 25 april 2018 @ 13:28:
[...]

Ik heb nu rustig alle blz. van dit topic gelezen. Ik heb vanochtend voor het eerst pi-hole geinstalleerd en de drie genoemde lists toegevoegd aan de standaard lists: de list van notrack, de mining list en de non-crossed wally3k. Mijn teller van geblokte domains staat op 127k. Nog al een verschil met de door jou genoemde 750k. Wat mis ik nog?

Geen idee, ik denk dat ik er dan toch eentje (of meer) ben vergeten te benoemen.

Hier een export van mijn lijsten;
https://j1nx.stackstorage.com/s/Fx2ZI02C0lL7D7X

meesje schreef op woensdag 25 april 2018 @ 11:58:
@j1nx Bedankt voor je reactie. Je tweak advies klinkt voor mij nog redelijk ingewikkeld. Tzt maar eens in verdiepen. Nu maar eerst eens alle opties nalopen.

Het valt op zich best mee, hieronder snelle pointers naar online documentatie. Doe er je voordeel mee, ook aan een ieder ander uiteraard.

1) Recursive truly self-contained DNS resolver

Ik zou de officieele Pi-Hole documentatie gebruiken. Allereerst moet je overschakelen naar de Beta FTLDNS versie. Vrij simpel en staat hier beschreven;
https://discourse.pi-hole...-us-beta-test-ftldns/8224

Daarna kun je unBound installeren en configureren zoals Pi-Hole ook zelf beschrijft hier.
https://github.com/pi-hol...e-as-recursive-DNS-server

2) DNS over HTTPS
Ik denk dat de beste stap voor stap documentatie hier te vinden is met gebruik van de DoH cloudflare client;
https://bendews.com/posts/implement-dns-over-https/

Met als enige remark, dat de laatste versie van FTLDNS nu dus gewoon "server=127.0.0.1#5053" accepteerd via de GUI. Dus het stukje "PiHole and dnsmas" onder "Configuring DNS" kun je gewoon overslaan / vervangen door via de GUI de onderste custom DNS op die localhost en 5053 te zetten.

3) DNS over TLS
Ook daar zijn verschillende manieren te vinden. Ik denk op dit moment is het het gemakkelijkst om gewoon het gehele stappen plan te volgen van Pi-Hole icm hun Recursive DNS (eerste optie) en dan de volgende wijzigingen toe te voegen helemaal onderaan de unBound config file;

code:

ssl-upstream: yes

forward-zone:
   name: "."
   #forward-addr: 9.9.9.9@853         # quad9.net primary
   forward-addr: 1.1.1.1@853         # cloudflare primary
   #forward-addr: 149.112.112.112@853 # quad9.net secondary
   forward-addr: 1.0.0.1@853         # cloudflare secondary

(met # kun je dingen uit-commenteren. Bovenstaande forward alle requests via SSL - TLS naar Cloudflare. Je kunt ook quad9 gebruiken en volgens mij ook de google servers)


Dan blijft voor mij en waarschijnlijk de rest de vraag; Welke optie is het beste?

Het lijkt er volgens mij op dat DNS-over-TLS het gaat winnen.
1) Het is een officieele standaard
2) Google gaat het out of de box ondersteunen vanaf Android-P

Ik hoor graag een ieder zijn mening daar over, al is dat misschien beter om dat in Het grote privacy-gerichte DNS server topic te doen.

[ Voor 66% gewijzigd door j1nx op 25-04-2018 14:14 ]

[grote_oever]

TRaSH schreef op woensdag 29 augustus 2018 @ 09:54:
Als de helft van de DNS request niet via de Pi lopen dan heb je volgens mij ergens je DNS verwijzing niet goed staan.
bv:
DNS 1 => Pi-Hole
DNS 2 => Een andere DNS service

Dan gaat hij random de DNS kiezen en dan gaat er de helft door de Pi-Hole en de andere helft rechtstreeks

Ik had een tijd een niet bestaand DNS server ingesteld als secondary DNS. De helft van de websites werkte toen. Secondary pakt hij volgens mij alleen als de primary niet te benaderen is(?!?!). Misschien ergens een time-out, want de pi was wel gewoon up. Maar goed, uiteindelijk ge-update na een pi3, want de site zelf was ook behoorlijk traag. Ik zal vast wat verkeerd gedaan hebben, maar hetzelfde trukje werkte wel voor de snellere pi.

[ Voor 5% gewijzigd door grote_oever op 29-08-2018 12:47 ]

[nero355]

Matheee schreef op vrijdag 1 maart 2019 @ 16:34:
Ook maar eens een groot deel terug gelezen.
Zit nu met het volgende:

Ik draai Pi-Hole op een Ubuntu Server (waar ook andere dingen op draaien). En heb nu een Raspberry Pi als backup Pi-Hole in gebruik. DHCP heb ik nog via mijn KPN Experiabox v10. Daarnaast staat Asus router als Access point in het netwerk.

Nu is het probleem: ik kan op de experiabox v10 maar 1 DNS server zetten. En ik zou graag een failover hebben, mocht 1 van de Pi-Holes om wat voor reden uitvallen.

Nu heb ik ook al gekeken of ik het ip van mijn Asus router als DNS-Server kon instellen, maar dit lijkt niet te werken als de in "Access point" mode staat.

Mmm... wat haat ik die term en dat misverstand!

Als je DNS over meerdere IP's wil verspreiden dan kan je beter kijken naar zoiets :
- https://discourse.pi-hole...-pihole-ive-done-it/12716
- https://www.reddit.com/r/...l/pihole_with_keepalived/
- https://github.com/manicholls/pi-hole-keepalived

Succes alvast!

Dat gedoe met Primary/Secondary/3rd/4rd DNS IP is namelijk nog steeds random en je client gaat ze echt niet 1 voor 1 af elke keer, maar zal dus elke keer willekeurig één IP adres kiezen!

Daarom hebben al die mensen op het Pi-Hole Forum last van random adblocking als ze als Secondary DNS IP die van Google of hun ISP gebruiken

[nero355]

Kenhas schreef op zaterdag 27 april 2019 @ 18:59:
Helemaal niet juist! Tweede dns wordt enkel gebruikt als back-up. Dat is nodig voor het geval pihole off Line geraakt om één of andere reden. Heb je geen tweede dns ingevuld en valt je pihole weg, heb je helemaal geen dns meer en kan je dus ook niet surfen. Alle dns requests gaan standaard naar dns1

Nee... Primary en Secondary DNS bestaan helemaal niet : Dat gebeurt willekeurig dus er is helemaal geen Fallback of iets dergelijks!

Vreselijk irritant misverstand trouwens dat wel vaker langskomt

ThinkPadd schreef op zaterdag 27 april 2019 @ 19:30:
Pi-hole zelf raadt aan om ook maar één DNS te gebruiken: https://discourse.pi-hole...e-my-only-dns-server/3376
Dit omdat veel systemen de tweede DNS als alternatief gebruiken i.p.v. fallback.

Heb het zelf nooit getest eigenlijk, je zou het kunnen testen door Wireshark te laten lopen, je tweede DNS op 8.8.8.8 oid zetten en dan gaan browsen en kijken of er ook requests naar 8.8.8.8 gaan i.p.v. Pi-hole.

Dat is gewoon zo : Je zal zien dat je Pi-Hole zelf ook zijn Forward DNS adressen random aanspreekt!

Als je een redundante Pi-Hole setup wilt dan kan je beter dit bouwen : https://discourse.pi-hole...-pihole-ive-done-it/12716

[jpgview]

sapphire schreef op zaterdag 30 mei 2020 @ 00:14:
Nee die Windows 10 desktop heeft geen IPV6 adres en ja de PC (en alle andere apparaten for that matter) gebruiken als DNS de router die op zijn beurt ingesteld staat om de Pi-Hole te gebruiken.

Waarom gebruiken je apparaten de router als DNS, waarom configureer je de apparaten (DHCP) niet zo dat ze als DNS server de pihole gebruiken?

vb.
router 192.168.2.1
pihole 192.168.2.10

DHCP instellingen: DNS 192.1682.10

Zorg ervoor dat je slechts één DNS server opgeeft (DHCP configuratie). Als de router dat niet toelaat, vul dan twee keer het IP address van de pihole in. Als dat ook niet mogelijk is, geef dan je pihole een secondary IP address, zodat je er twee verschillende kan opgeven.
De benaming secondary DNS is vreselijk misleidend, er zijn tientallen topics op discourse, die dit aangeven. Als je een primary and secondary DNS opgeeft, zullen beide gebruikt worden…

Ik kan me niet voorstellen dat dit een pihole v5 bug is, Vier maanden beta test, door ervaren gebruikers, geen klachten. Als dit een bug zou zijn in de final release, zou discourse verzuipen in de topics over blocking problemen, dat is niet zo.

nero355 schreef op zaterdag 30 mei 2020 @ 00:44:
Wat ik wel heb gedaan bij mij meteen na de installatie : Alle bekende apparaten handmatig in een hernoemde Default Group gezet!

Alle apparaten, die niet als client zijn gedefineerd (group management) zijn per definitie member van the default group.
In mijn manual geef ik aan (sectie 9) hoe je een local LAN lijst kan maken, wat het probleem 'IP address i.p.v. device name' oplost. Ik weet dat er nu via met menu 'Local DNS Records' kunnen aangemaakt worden, maar die lijst voldoet niet aan de hosts file specification. In de manual, sectie 17.2 staat ook een script, om die lijst scripted te importeren in pihole.
Ik raad iedereen aan om DHCP fixed IP addressen te gebruiken (gebaseerd op het MAC address), om toekomstige ellende te voorkomen.

[ Voor 38% gewijzigd door jpgview op 30-05-2020 09:17 ]

[sapphire]

jpgview schreef op zaterdag 30 mei 2020 @ 08:59:
[...]


Waarom gebruiken je apparaten de router als DNS, waarom configureer je de apparaten (DHCP) niet zo dat ze als DNS server de pihole gebruiken?

vb.
router 192.168.2.1
pihole 192.168.2.10

DHCP instellingen: DNS 192.1682.10

Zorg ervoor dat je slechts één DNS server opgeeft (DHCP configuratie). Als de router dat niet toelaat, vul dan twee keer het IP address van de pihole in. Als dat ook niet mogelijk is, geef dan je pihole een secondary IP address, zodat je er twee verschillende kan opgeven.
De benaming secondary DNS is vreselijk misleidend, er zijn tientallen topics op discourse, die dit aangeven. Als je een primary and secondary DNS opgeeft, zullen beide gebruikt worden…

Ik kan me niet voorstellen dat dit een pihole v5 bug is, Vier maanden beta test, door ervaren gebruikers, geen klachten. Als dit een bug zou zijn in de final release, zou discourse verzuipen in de topics over blocking problemen, dat is niet zo.


[...]


Alle apparaten, die niet als client zijn gedefineerd (group management) zijn per definitie member van the default group.
In mijn manual geef ik aan (sectie 9) hoe je een local LAN lijst kan maken, wat het probleem 'IP address i.p.v. device name' oplost. Ik weet dat er nu via met menu 'Local DNS Records' kunnen aangemaakt worden, maar die lijst voldoet niet aan de hosts file specification. In de manual, sectie 17.2 staat ook een script, om die lijst scripted te importeren in pihole.
Ik raad iedereen aan om DHCP fixed IP addressen te gebruiken (gebaseerd op het MAC address), om toekomstige ellende te voorkomen.

De router kan prima omgaan met 1 DNS, de 2e heb ik nooit ingesteld staan. Ja nu omdat ik die suggestie kreeg heb ik 2x de Pihole, 1 of 2x hetzelfde hetzelfde heeft de router geen problemen mee.
En waarom en router als DNS? Omdat het out of the box zo werkt. Router handeld de DHCP af en alle DNS requests stuurt hij door naar de Pihole. Als ik alle devices handmatig een DNS moet gaan instellen heeft 1 centrale DNS imho weinig nut en is niet altijd mogelijk als devices dichtgetimmerd zijn.

Zal vanavond of morgen eens de groups opnieuw instellen

Overigens zegt 4 maanden beta testen door ervaren gebruikers niets
De Adobe suite zit ook vol bugs ondanks uitgebreid testen, Radeon drivers idem. Ik werk dagelijks met Topdesk, guess what loop dagelijks tegen bugs aan die er al jaren inzitten
Zelf betatester geweest van wat Netgear spullen, zitten ook genoeg bugs nog in

[Klippy]

Dr. Mabuse schreef op woensdag 3 juni 2020 @ 17:44:
[...]


Ik krijg precies dezelfde foutmelding , echter alles lijkt goed te draaien
in /etc/resolv.conf staat ook geen verwijzing naar 127.0.0.11

ik gebruik portainer 1.23.2 en heb volgende handleiding gebruikt. https://servicemax.com.au...on-synology-the-best-way/

In de handleiding staat wel een screenshot waar ze de container DNS zetten, onder de tekst

The Primary DNS must be the localhost so put in 127.0.0.1, and I’m using Getflix so I’ll make the Secondary DNS 54.252.183.5 but this probably won’t work for you

127.0.0.11 is de DNS van de Docker service, zodat de containers elkaar kunnen vinden, als je geen --dns flag meegeeft zal dat de eerste DNS service zijn, vandaar de melding.

[nero355]

Verwijderd schreef op zaterdag 4 juli 2020 @ 18:04:
Dat heb ik op mijn OnePlus ook.
Heb het opgelost door mijn PiHole zowel via LAN als WiFi aan te sluiten op mijn netwerk.
De twee IP's heb ik dan in DHCP opgegeven.
En weg was de Google DNS op mijn telefoon.

2x hetzelfde IP werkte niet.

Je kan gewoon een alias toevoegen aan je bestaande ethernet interface

Ik zou het echter niet zo doen :

jpgview schreef op zaterdag 4 juli 2020 @ 22:07:
prima oplossing, maar het kan ook eenvoudiger:
pihole luistert op een bepaalde interface (bij mij interface=eth0 in /etc/dnsmasq.d/01-pihole.conf)
door een secondary IP address toe te voegen heb je ook twee IPs ter beschikking en word alles via ethernet afgehandeld.

de eenvoudigste manier om een secondary IP toe te voegen (Raspberry Pi OS (32-bit) Lite - may 2020):
- maak een bestand /etc/dhcpcd.exit-hook (naam is belangrijk, niet wijzigen)
- content (wel IP, mask en interface aanpassen):

[...]

-reboot

Maar gewoon aan dhcpcd.conf toevoegen op de reguliere manier en dan ook effe aan Pi-Hole doorgeven dat die daarop moet luisteren

kosz schreef op zaterdag 4 juli 2020 @ 22:35:
Een hoop devices en applicaties gaan primary naar google DNS, al stuur je de primary en secundary vanuit je DHCP naar je pi-hole. Ik heb in mn fortigate firewall nu alleen DNS verkeer vanaf mn pi-holes toegelaten, dan pakken al mijn netwerk devices uiteindelijk deze ipv de hardcoded naar google.
Er was gewoon teveel verkeer wat toch naar de google DNSsen ging.

8.8.8.8 en 8.8.4.4 routeren naar een niet bestaand adres kan ook, want dan kunnen al die stomme Google apparaten de lokale DNS ineens wel vinden!

kosz schreef op zaterdag 4 juli 2020 @ 22:55:
Nee dus, mn Shield TV, google nest mini, eneco toon gebruiken gewoon lekker 8.8.8.8... pas bij een implicit deny doen ze de dhcp toegewezen pi-hole gebruiken.... echt heel smerig

Hmm... dat is best wel raar, want mijn nVidia Shield TV 2017 gebruikt gewoon mijn lokale DNS Server i.t.t. de Google Chromecast Ultra bijvoorbeeld

[Zanbee]

Wachten... schreef op donderdag 10 december 2020 @ 13:09:
@Dracula
...

Kortgezegd wordt de PiHole dus eigenlijk je LAN DNS setting, tenzij deze wegvalt en hij dus je secondary oppakt in je LAN settings. En daarnaast heeft de PiHole dus de extra magische functie m.b.t. Blacklist e.d. zodat hij kan gaan filteren.

Het is even snel getypt, dus hoop dat je mijn/de logica een beetje snapt, Echter kan ik ernaast zitten, want zoals gezegd ben ik geen network engineer. Ik hoop dat iemand mij dan weer kan verbeteren!

Ik heb altijd begrepen dat er ook als de primary actief is er geregeld de secondary geraadpleegt werd. Waardoor je ondanks dat PiHole actief er ongewenste resultaten terug kunnen komen.

Er was ook niet zoiets als primary secondary dns dacht ik. Maar meer dat je gewoon meerdere servers kan op geven. Waar min of meer ad random een verzoek naar toe gaat.

Nu moet ik wel bekennen voornamelijk met Linux te werken geen idee of het voor Windows ook zo werkt.

Hier iemand die het ook onderzocht heeft: Using Pi-Hole to investigate DNS 1 vs. 2 usage

[ Voor 21% gewijzigd door Zanbee op 10-12-2020 13:49 ]

[Wachten...]

Zanbee schreef op donderdag 10 december 2020 @ 13:41:
[...]


Ik heb altijd begrepen dat er ook als de primary actief is er geregeld de secondary geraadpleegt werd. Waardoor je ondanks dat PiHole actief er ongewenste resultaten terug kunnen komen.

Er was ook niet zoiets als primary secondary dns dacht ik. Maar meer dat je gewoon meerdere servers kan op geven. Waar min of meer ad random een verzoek naar toe gaat.

Nu moet ik wel bekennen voornamelijk met Linux te werken geen idee of het voor Windows ook zo werkt.

Hier iemand die het ook onderzocht heeft: Using Pi-Hole to investigate DNS 1 vs. 2 usage

Dat zou heel goed kunnen hoor, zoals gezegd ben ik geen expert. Echter als ik kijk naar de advertenties die geblockt worden, dan werkt naar mijn idee de PiHole (primary DNS) hier altijd. Als ik ook maar 30 seconden de PiHole uitzet, omdat ik even iets moet testen, dan merk ik dit direct qua snelheid en ads op mijn netwerk.

Persoonlijk heb ik dus niet het idee dat de secondary vaak geraadpleegd wordt, en als het gebeurt, dan zal het echt op zo`n kleine schaal zijn, dat het niet merkbaar is! Maar desondanks is het dus inderdaad goed om sowieso een secondary in te stellen

Hier iemand die het ook onderzocht heeft: Using Pi-Hole to investigate DNS 1 vs. 2 usage

Interessant stuk. Zou het ook nog zo kunnen zijn dat bijvoorbeeld de Raspberry pi Zero niet krachtig genoeg is om alles te kunnen verwerken en dus de secondary het oppakt?

Wat ik zeg, ik draai hier een PiHole op de Raspberry pi 3B+ en heb nou totaal niet het idee dat hij vaak naar mijn secondary gaat. Ik merk het op alle vlakken echt direct, zodra ik de PiHole maar even uitzet.

Dit is uiteraard niet echt een legit test dan wat ik doe, maar het is meer een praktijk gevoel/ervaring.
Misschien hebben andere een primary en secondary PiHole op een iets krachtiger apparaat en kunnen zij hier iets zinnigs over zeggen?

Anders is het zelf ook nog wel leuk om te testen, Ik heb nog een aantal Raspberry pi 3B+ hier liggen, dus misschien ga ik deze eens als secondary opzetten binnen mijn netwerk en kijken wat het doet!

[ Voor 27% gewijzigd door Wachten... op 10-12-2020 14:08 ]

[Freee!!]

Wachten... schreef op donderdag 10 december 2020 @ 14:01:
[...]


Dat zou heel goed kunnen hoor, zoals gezegd ben ik geen expert. Echter als ik kijk naar de advertenties die geblockt worden, dan werkt naar mijn idee de PiHole (primary DNS) hier altijd. Als ik ook maar 30 seconden de PiHole uitzet, omdat ik even iets moet testen, dan merk ik dit direct qua snelheid en ads op mijn netwerk.

Persoonlijk heb ik dus niet het idee dat de secondary vaak geraadpleegd wordt, en als het gebeurt, dan zal het echt op zo`n kleine schaal zijn, dat het niet merkbaar is! Maar desondanks is het dus inderdaad goed om sowieso een secondary in te stellen


[...]


Interessant stuk. Zou het ook nog zo kunnen zijn dat bijvoorbeeld de Raspberry pi Zero niet krachtig genoeg is om alles te kunnen verwerken en dus de secondary het oppakt?

Wat ik zeg, ik draai hier een PiHole op de Raspberry pi 3B+ en heb nou totaal niet het idee dat hij vaak naar mijn secondary gaat. Ik merk het op alle vlakken echt direct, zodra ik de PiHole maar even uitzet.

Dit is uiteraard niet echt een legit test dan wat ik doe, maar het is meer een praktijk gevoel/ervaring.
Misschien hebben andere een primary en secondary PiHole op een iets krachtiger apparaat en kunnen zij hier iets zinnigs over zeggen?

Anders is het zelf ook nog wel leuk om te testen, Ik heb nog een aantal Raspberry pi 3B+ hier liggen, dus misschien ga ik deze eens als secondary opzetten binnen mijn netwerk en kijken wat het doet!

Ik heb hier twee Pi-Holes, ieder op een eigen RPi (een RPi4B en een RPi3B+) en ze worden beide geraakt. De Pi-Hole op de RPi3B+ een stuk minder, want die is wat minder krachtig en staat als secondary ingesteld, maar wordt nog steeds wel geraakt (3.701 om 17.532 keer in de laatste 24 uur ).

[nero355]

Wachten... schreef op donderdag 10 december 2020 @ 12:39:
Zijn vraag is alleen wat de logica hier achter is.

Er zijn meerdere wegen die naar Rome leiden, maar is het de juiste? en waarom/wanneer verkies je het één boven het ander?

Misschien hebben beide gewoonweg die functie, doen ze exact hetzelfde en bestaat er dus geen 'beste' optie of logica?

Nou... zo beter dan :

Dracula schreef op donderdag 10 december 2020 @ 12:55:
Precies dat, ja beide methodes kan maar welke ligt het meest voor de hand.

Degene die het meest voor de hand ligt is degene die je al gebruikt

Persoonlijk vind ik die ook het beste, maar dan i.c.m. Unbound vanwege het DNS Servers gezeik dat door allerlei DDoS acties enkele weken geleden een probleem werd bij Ziggo/Caiway/T-Mobile geloof ik...
Terwijl iedereen problemen had merkte ik er amper wat van!

Wachten... schreef op donderdag 10 december 2020 @ 13:09:
WAN
Je WAN DNS wil je verwijzen naar iets wat altijd online is, en niet af wilt laten hangen van je PiHole (als deze er tussenuit valt, hebt je niks) Ik heb hier bijvoorbeeld de OpenDNS gebruikt 208.67.222.222 en 208.67.220.220

Wederom : Het is een keuze

Zover ik weet heeft deze DNS ook niks met je LAN apparaten te maken, vandaar dat het WAN is.

Elke Router gebruikt de WAN DNS Servers als de Forward DNS Servers voor zijn LAN Clients als Default Setting

De software waarop Pi-Hole deels op gebaseerd is genaamd DNSmasq en omgedoopt en geforked is tot FTLDNS draait namelijk ook op zo'n beetje elke Router die je in de winkel vindt

LAN
Je LAN settings laat je verwijzen naar je PiHole. Dit gaat om alle apparaten binnen jouw netwerk.
Hier geef je als primair DNS de PiHole op, en als secondary iets van OpenDNS of wat anders. Mocht je PiHole er namelijk tussenuit vallen, dan heb je nog steeds internet, omdat je als backup (secondary) de OpenDNS hebt aangegeven.

Dat moet je dus inderdaad niet doen!

PiHole word je LAN DNS setting
Als je dan iets opzoekt met je mobiel, dan wordt je doorgestuurd naar de DNS van je PiHole (want zo is de LAN DNS ingesteld) en in je Pihole geef je vervolgens weer aan welke DNS je daar wilt gebruiken. Je moet het zo zien dat je LAN DNS dus zegt, "hey PiHole regel jij de DNS maar" En of je dan in je PiHole OpenDNS of Google DNS of wat dan ook gebruikt, dan maakt niet uit. De DNS die je daar gebruikt, overschrijft eigenlijk de DNS setting in je LAN tenzij je PiHole wegvalt. Mocht je PiHole dus wegvallen, dan gaat deze alsnog kijken naar je secondary DNS in je LAN settings.

Als één van je DNS Servers wegvalt heb je ook kans dat er een korte, maar helaas merkbare vertraging optreedt op het moment dat je een webpagina opvraagt dus eigenlijk kan je beter iets van een VRRP setje draaien voor je Pi-Hole setup, zoals het al een paar keer is genoemd in dit topic in het verleden inclusief een aantal tutorials op het officiële Pi-Hole Forum

En daarnaast heeft de PiHole dus de extra magische functie m.b.t. Blacklist e.d. zodat hij kan gaan filteren.

NICE!

Wachten... schreef op donderdag 10 december 2020 @ 14:01:
Interessant stuk. Zou het ook nog zo kunnen zijn dat bijvoorbeeld de Raspberry pi Zero niet krachtig genoeg is om alles te kunnen verwerken en dus de secondary het oppakt?

De een kan niet ruiken hoe snel de ander is dus dat heeft er helemaal niks mee te maken!

Zanbee schreef op donderdag 10 december 2020 @ 13:41:
Ik heb altijd begrepen dat er ook als de primary actief is er geregeld de secondary geraadpleegt werd. Waardoor je ondanks dat PiHole actief er ongewenste resultaten terug kunnen komen.

Er was ook niet zoiets als primary secondary dns dacht ik. Maar meer dat je gewoon meerdere servers kan op geven. Waar min of meer ad random een verzoek naar toe gaat.

Klopt helemaal!

Nu moet ik wel bekennen voornamelijk met Linux te werken geen idee of het voor Windows ook zo werkt.

Er schijnt wat verschil tussen te zitten, maar uiteindelijk komt het op hetzelfde neer

Hier iemand die het ook onderzocht heeft: Using Pi-Hole to investigate DNS 1 vs. 2 usage

Ik ben het helemaal eens met zijn Conclusie :

- Don’t set a public DNS server as DNS 2 if you want airtight Pi-Hole protection
- Set up a second Pi-Hole if you need redundancy
- Man, I wish there was a Raspberry Pi Zero with wired internet!

[Wachten...]

@nero355

LAN
Je LAN settings laat je verwijzen naar je PiHole. Dit gaat om alle apparaten binnen jouw netwerk.
Hier geef je als primair DNS de PiHole op, en als secondary iets van OpenDNS of wat anders. Mocht je PiHole er namelijk tussenuit vallen, dan heb je nog steeds internet, omdat je als backup (secondary) de OpenDNS hebt aangegeven.
----------------------------------------------------
Dat moet je dus inderdaad niet doen!

Bedoel je dan een secondary instellen zoals OpenDNS? Of heb je het hier over de LAN settings (router settings) naar je PiHole verwijzen? En kun je dan uitleggen wat daar daadwerkelijk "fout" aan is? Ik wil ook nog een keer goed kijken naar al mijn settings en dingen fine-tunen namelijk!

Wachten... schreef op donderdag 10 december 2020 @ 14:01:
Interessant stuk. Zou het ook nog zo kunnen zijn dat bijvoorbeeld de Raspberry pi Zero niet krachtig genoeg is om alles te kunnen verwerken en dus de secondary het oppakt?
-----------------------------------------------------
De een kan niet ruiken hoe snel de ander is dus dat heeft er helemaal niks mee te maken!

Ik bedoelde het niet in de zin dat de één de andere voor laat omdat deze krachtiger is, maar gewoon puur omdat deze meer kan verwerken.

Dus stel je hebt een krachtige PC als DNS server met Pihole en een Pi one, en je gaat een week lang de PC als primary opgeven en de Pi one als secondary en na een week exact dezelfde activiteiten doen, maar dan de DNS primary en secondary omdraaien (Pi one als pirmairy en PC als secondary), dan was ik benieuwd of je dezelfde verdeling/blockhits krijgt op beide......

[nero355]

Webgnome schreef op donderdag 10 december 2020 @ 19:23:
Misschien een domme vraag maar waar kan ik de blacklist vinden? Ik heb net mijn pihole die de dhcp ook regelt zo ingesteld dat ie de tweede pihole als tweede dns moet mee geven maar ik wil graag die twee in sync houden. De lossse blocklists had ik al gedaan maar de blacklit die ik via de ui heb aangevuld waar kan ik die vinden?

p.s. zelfde ook voor de whitelist van belang natuurlijk.

Volgens mij staat alles hier :

root@unipi:/etc/pihole# ls -a
.                 gravity.list                               local.list
..                install.log                                localversions
adlists.list      list.1.raw.githubusercontent.com.domains   logrotate
black.list        list.2.mirror1.malwaredomains.com.domains  macvendor.db
custom.list       list.3.sysctl.org.domains                  migration_backup
dhcp.leases       list.4.zeustracker.abuse.ch.domains        pihole-FTL.conf
dns-servers.conf  list.5.s3.amazonaws.com.domains            pihole-FTL.db
GitHubVersions    list.6.s3.amazonaws.com.domains            setupVars.conf
gravity.db        localbranches                              setupVars.conf.update.bak
root@unipi:/etc/pihole# 

Ik weet effe niet meer wat er veranderd is qua "losse bestanden vs. database records" tijdens één van de grote updates in het verleden, maar daar moet je het in ieder geval in zoeken

Wachten... schreef op donderdag 10 december 2020 @ 21:12:
Bedoel je dan een secondary instellen zoals OpenDNS? Of heb je het hier over de LAN settings (router settings) naar je PiHole verwijzen? En kun je dan uitleggen wat daar daadwerkelijk "fout" aan is? Ik wil ook nog een keer goed kijken naar al mijn settings en dingen fine-tunen namelijk!

Gewoon wat er al besproken is : Al je Clients moeten alleen met Pi-Hole communiceren en niet met andere externe servers

Verder valt er weinig te finetunen in principe :
- RaspBian of hoe dat ook heet tegenwoordig installeren.
- Pi-Hole installeren.
- Eventueel Unbound.
- Upstream DNS Servers installeren.
- De DHCP Settings van je Router aanpassen qua DNS Servers die de Clients krijgen.

En gaaaan met die banaan!

Ik bedoelde het niet in de zin dat de één de andere voor laat omdat deze krachtiger is, maar gewoon puur omdat deze meer kan verwerken.

Een beetje DNS Queries beantwoorden kan zelfs een Pi 2B of Zero helemaal prima dus daar hoef je echt niet aan te twijfelen

De meeste routers die je in de winkel koopt hebben zelfs vaak nog minder rekenkracht gehad in het verleden!

Dus stel je hebt een krachtige PC als DNS server met Pihole en een Pi one, en je gaat een week lang de PC als primary opgeven en de Pi one als secondary en na een week exact dezelfde activiteiten doen, maar dan de DNS primary en secondary omdraaien (Pi one als pirmairy en PC als secondary), dan was ik benieuwd of je dezelfde verdeling/blockhits krijgt op beide...

Ik zou zeggen ga het testen en laat je bevindingen weten, maar het zal denk ik niet veel uitmaken waarop ze draaien uiteindelijk

[Andre PE1PQX]

Goeden oude jaars dag allen,

Ik vraag me het volgende af: heeft het zin/nut om een 2e Pi-Hole te laten draaien en je netwerk om alle vervelende advertenties te weren?
Op dit moment draait er één Pi-Hole in mijn Unified LAN tot grote tevredenheid, maar is een 2e ook echt handiger/beter/aan te bevelen? Je zou dan je primary DNS en je secondary DNS ieders op 2 verschillende Pi-Holes kunnen laten draaien.

Waarom wel/Waarom niet? (doorhalen wat NIET je voorkeur is)

[Freee!!]

Andre PE1PQX schreef op donderdag 31 december 2020 @ 16:32:
Goeden oude jaars dag allen,

Ik vraag me het volgende af: heeft het zin/nut om een 2e Pi-Hole te laten draaien en je netwerk om alle vervelende advertenties te weren?
Op dit moment draait er één Pi-Hole in mijn Unified LAN tot grote tevredenheid, maar is een 2e ook echt handiger/beter/aan te bevelen? Je zou dan je primary DNS en je secondary DNS ieders op 2 verschillende Pi-Holes kunnen laten draaien.

Waarom wel/Waarom niet? (doorhalen wat NIET je voorkeur is)

Ik heb een tweede Pi-Hole (op een tweede RPi). Soms gaat er wel eens iets mis met een RPi en op die manier is er eigenlijk altijd minimaal één Pi-Hole actief. Zo had ik ergens vorige week een stroomstorinkje (stop eruit geklapt, oorzaak onbekend) en van één RPi bleek de hele Docker niet meer op te komen en dit was ook niet te repareren. Terugflashen van een backup-image bleek ook niet te werken (is in het verleden vaak genoeg wel goed gegaan), dus ik was blij een werkende internetverbinding met Pi-Hole te hebben terwijl ik die RPi opnieuw inrichtte.

[roeleboel]

Andre PE1PQX schreef op donderdag 31 december 2020 @ 16:32:
Goeden oude jaars dag allen,

Ik vraag me het volgende af: heeft het zin/nut om een 2e Pi-Hole te laten draaien en je netwerk om alle vervelende advertenties te weren?
Op dit moment draait er één Pi-Hole in mijn Unified LAN tot grote tevredenheid, maar is een 2e ook echt handiger/beter/aan te bevelen? Je zou dan je primary DNS en je secondary DNS ieders op 2 verschillende Pi-Holes kunnen laten draaien.

Waarom wel/Waarom niet? (doorhalen wat NIET je voorkeur is)

Er zijn een aantal apparaten (kuch - smartphone - kuch - chromecast - kuch etc) die hun eigen ding doen qua dns (dus die van google zelf gebruiken) als je maar 1 dns-server instelt. Een deel (helaas niet allemaal) luistert wel naar je settings als je 2 dns-servers opgeeft...

Alternatief hiervoor is een firewall zorgen die alle buitengaande dns-requests die niet van je pihole komen doorlust naar je pihole, maar de meeste consumentenrouters ondersteunen zoiets niet.

[ Voor 10% gewijzigd door roeleboel op 31-12-2020 17:31 ]

[ed1703]

Andre PE1PQX schreef op donderdag 31 december 2020 @ 16:32:
Goeden oude jaars dag allen,

Ik vraag me het volgende af: heeft het zin/nut om een 2e Pi-Hole te laten draaien en je netwerk om alle vervelende advertenties te weren?
Op dit moment draait er één Pi-Hole in mijn Unified LAN tot grote tevredenheid, maar is een 2e ook echt handiger/beter/aan te bevelen? Je zou dan je primary DNS en je secondary DNS ieders op 2 verschillende Pi-Holes kunnen laten draaien.

Waarom wel/Waarom niet? (doorhalen wat NIET je voorkeur is)

Voor mij vooral “omdat het kan” ik heb 2 pi’s in 2 ha vrrp groepjes draaien waarbij zowel de primaire als de secundaire qua ip altijd wel benaderd kunnen worden.

Uiteraard met een IP-adres eindigt op .53 en .153 😝

[jpgview]

dss58 schreef op dinsdag 19 januari 2021 @ 18:35:
[...]
jmaar het zijn geen domains die uit pihole2 komen maar vanaf de clients

wil volgens mij zeggen dat die clients niet de correcte dns server hebben (niet pihole1) of die clients pihole1 en pihole2 als dns servers hebben.

Zoals al vele malen aangegeven, de benaming die microsoft in de dns settingsgebruikt (primary en secondary) geven niet de werkelijkheid aan. beide dns servers zullen gebruikt worden, wat dus client entries op pihole2 zou kunnen verklaren, lees o.a. hier (DL6ER is the lead pihole FTL developer)

[dss58]

jpgview schreef op dinsdag 19 januari 2021 @ 18:57:
[...]


wil volgens mij zeggen dat die clients niet de correcte dns server hebben (niet pihole1) of die clients pihole1 en pihole2 als dns servers hebben.

Zoals al vele malen aangegeven, de benaming die microsoft in de dns settingsgebruikt (primary en secondary) geven niet de werkelijkheid aan. beide dns servers zullen gebruikt worden, wat dus client entries op pihole2 zou kunnen verklaren, lees o.a. hier (DL6ER is the lead pihole FTL developer)

zoals ik later in de edit aan gaf, het eenvoudigste is om de boel opnieuw van scrach te installeren, binnen een half uurtje draait ie vast weer als een zonnetje, en de meeste tijd zit in het wachten

[mithras]

@dionio @deHakkelaar @synoniem zijn jullie bekend met dual pihole sync 2.0?

Een bash script draait in een cron op een primary pi-hole en stuurt elke 5 minuten een update van de files naar de 2e pi-hole. Het blijft een active-active setup, waar de primary de secondary voedt en ze zo min of meer in sync zijn met whitelists/blacklists etc. Bij een wijziging in de file wordt gravity ook opnieuw geladen.

Heb zelf nog geen 2e pi draaien hiermee (ben dat nog van plan) maar wilde het wel via deze techniek in sync houden. Je primary is dan de interface waar je zelf alle wijzigingen doorvoert waar nodig.

[deHakkelaar]

Aha ik snap nu wat je bedoelt met "zone forward".
Ik verwarde dit met DNS zone transfers (primary/secondary etc).
Jij hebt het over de forward-zone: "directive" in unbound:

pi@ph5a:~ $ man unbound.conf
[..]
   Forward Zone Options
       There may be multiple forward-zone: clauses. Each with a name: and zero
       or more hostnames or IP addresses.  For the forward zone this  list  of
       nameservers  is  used  to forward the queries to. The servers listed as
       forward-host: and forward-addr: have to handle  further  recursion  for
       the  query.   Thus,  those  servers  are not authority servers, but are
       (just like unbound is) recursive servers too; unbound does not  perform
       recursion itself for the forward zone, it lets the remote server do it.
       Class IN is assumed.  CNAMEs are chased by unbound itself,  asking  the
       remote  server  for every name in the indirection chain, to protect the
       local cache from illegal indirect referenced items.  A forward-zone en‐
       try with name "." and a forward-addr target will forward all queries to
       that other server (unless it can answer from the cache).

       name: <domain name>
              Name of the forward zone.

       forward-host: <domain name>
              Name of server to forward to. Is itself resolved  before  it  is
              used.

       forward-addr: <IP address>
              IP address of server to forward to. Can be IP 4 or IP 6.  To use
              a nondefault port for DNS communication append '@' with the port
              number.   If  tls  is  enabled,  then you can append a '#' and a
              name, then it'll check the tls authentication certificates  with
              that name.  If you combine the '@' and '#', the '@' comes first.

pi@ph5a:~ $ sudo nano /etc/unbound/unbound.conf.d/forward-zone.conf
forward-zone:
        name: "services.ing.nl."
        forward-addr: 1.1.1.1
        forward-addr: 8.8.8.8

pi@ph5a:~ $ sudo service unbound reload
pi@ph5a:~ $

pi@ph5a:~ $ sudo unbound-control lookup services.ing.nl
The following name servers are used for lookup of services.ing.nl.
forwarding request:
Delegation with 0 names, of which 0 can be examined to query further addresses.
It provides 2 IP addresses.
1.1.1.1                 not in infra cache.
8.8.8.8                 not in infra cache.

pi@ph5a:~ $ sudo unbound-control lookup gathering.tweakers.net
The following name servers are used for lookup of gathering.tweakers.net.
;rrset 86379 3 0 2 0
tweakers.net.   86379   IN      NS      tweakdns.be.
tweakers.net.   86379   IN      NS      tweakdns.nl.
tweakers.net.   86379   IN      NS      tweakdns.eu.
[..]

Mijn foutje ... oops
Maar dat had je wel even kunnen vermelden in wat meer details
Het raadsel blijft helaas waarom je dit moet doen omdat het recursief niet lukt???

[nero355]

R009 schreef op dinsdag 13 juli 2021 @ 14:38:
Ik hoop dat iemand me hier kan helpen met het volgende probleem. Ik heb Pi-Hole op een Raspberry Pi geïnstalleerd en deze op mijn Fritzbox 7590 een vast IP adres gegeven. Op de Fritzbox ben ik dan naar Internet - toegangsgegevens - DNS-Server tabje gegaan.

Daar heb ik "Andere DNSv4-server gebruiken" geselecteerd en vervolgens het IP adres van Pi-Hole als voorkeurs-DNSv4-Server ingegeven en 195.238.2.22 als alternatieve DSNv4-Server ingegeven (DNS van Proximus).

Wanneer ik de Pi-Hole zonder stroom zet, neemt de alternatieve DNS alles over. Ik geraak dus nog steeds op het internet. Echter wanneer ik de Pi-Hole terug opstart blijven mijn DNS request worden afgehandeld door de alternatieve DNS en niet door de Pi-Hole

Heeft er iemand een idee hoe ik ervoor zorg dat als mijn Pi-Hole terug online komt, mijn Fritzbox deze terug als DNS server gaat gebruiken?

Je bent gewoon helemaal verkeerd bezig, zoals vele anderen die je voor zijn gegaan!

Pak de Search bovenaan erbij en zoek eens op termen zoals VRRP en Primary en Secondary DNS en je komt er vanzelf wel achter hoe het WEL moet

[deHakkelaar]

R009 schreef op dinsdag 13 juli 2021 @ 14:38:
Hallo,

Ik hoop dat iemand me hier kan helpen met het volgende probleem. Ik heb Pi-Hole op een Raspberry Pi geïnstalleerd en deze op mijn Fritzbox 7590 een vast IP adres gegeven. Op de Fritzbox ben ik dan naar Internet - toegangsgegevens - DNS-Server tabje gegaan.

Daar heb ik "Andere DNSv4-server gebruiken" geselecteerd en vervolgens het IP adres van Pi-Hole als voorkeurs-DNSv4-Server ingegeven en 195.238.2.22 als alternatieve DSNv4-Server ingegeven (DNS van Proximus).

Wanneer ik de Pi-Hole zonder stroom zet, neemt de alternatieve DNS alles over. Ik geraak dus nog steeds op het internet. Echter wanneer ik de Pi-Hole terug opstart blijven mijn DNS request worden afgehandeld door de alternatieve DNS en niet door de Pi-Hole

Heeft er iemand een idee hoe ik ervoor zorg dat als mijn Pi-Hole terug online komt, mijn Fritzbox deze terug als DNS server gaat gebruiken?

Is doc voor Fritz:
https://docs.pi-hole.net/routers/fritzbox/

En wbt primary/secondary DNS etc:
https://discourse.pi-hole...e-my-only-dns-server/3376

[R009]

deHakkelaar schreef op dinsdag 13 juli 2021 @ 23:16:
[...]


Is doc voor Fritz:
https://docs.pi-hole.net/routers/fritzbox/

En wbt primary/secondary DNS etc:
https://discourse.pi-hole...e-my-only-dns-server/3376

bedankt voor de duidelijke post en handleidingen!

[dss58]

ik heb 2 raspberry pi's als pihole, primary wijst naar de eerste, secondary DNS naar de andere, krijg je leuk inzicht tussen die 2

[Freee!!]

dss58 schreef op vrijdag 22 december 2023 @ 23:28:
ik heb 2 raspberry pi's als pihole, primary wijst naar de eerste, secondary DNS naar de andere, krijg je leuk inzicht tussen die 2

Wordt nog leuker als je nog meer Pi-Holes hebt draaien, ik heb er vijf verdeeld over drie RPi's, één RPi fungeert ook als DHCP-server (ooit problemen met de DHCP-functie van modem) en geeft dus vijf DNS'en door.

code:

Wireless LAN adapter Wi-Fi 2:

   Connection-specific DNS Suffix  . : Whiskey
   Description . . . . . . . . . . . : Qualcomm Atheros QCA9377 Wireless Network Adapter #2
   Physical Address. . . . . . . . . : 20-4E-F6-F9-6B-49
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9811:7c90:a231:6af7%14(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.2.44(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : zaterdag 23 december 2023 09:35:25
   Lease Expires . . . . . . . . . . : zondag 24 december 2023 09:35:25
   Default Gateway . . . . . . . . . : 192.168.2.254
   DHCP Server . . . . . . . . . . . : 192.168.2.231
   DHCPv6 IAID . . . . . . . . . . . : 639651574
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2D-0F-4A-9F-20-4E-F6-F9-6B-49
   DNS Servers . . . . . . . . . . . : 192.168.2.239
                                       192.168.2.219
                                       192.168.2.235
                                       192.168.2.215
                                       192.168.2.249
   NetBIOS over Tcpip. . . . . . . . : Enabled

[ Voor 57% gewijzigd door Freee!! op 23-12-2023 11:47 ]

[ApC_IcE]

Over iedereen qua discussie met pihole als primary DNS en bijvoorbeeld 1.1.1.1. oid als secondary:

Ik kreeg opeens op mijn mac constant overal reclame. Terwijl alles al 2-3 jaar stabiel draait op mijn pi.
Ik ging eens kijken naar de DNS in de mac (dacht eerst aan een apple relay omdat ik dat als " whitelist". in de Pi hole vond.
Uiteindelijk stonden er dus 2 DNS adressen ingevuld in de unifi omgeving.
Dit veranderd naar alleen een primary en alles werkt weer zoals het is.

Dit bewijst soort van ook weer dan als een device besloten heeft dat de secondary sneller is of wat dan ook dat een single DNS beter werkt. Tenzij die uitvalt. Dan moet ik thuis in de router aan de slag.
Of inderdaad een 2e Pihole als secondary.

Ik bedenk met net opeens dat ik de DNS cache ook geflusht heb. Dus dan had hij wellicht ook weer naar de primary gekeken.

[Webgnome]

ApC_IcE schreef op zaterdag 23 december 2023 @ 13:15:
Over iedereen qua discussie met pihole als primary DNS en bijvoorbeeld 1.1.1.1. oid als secondary:

Ik kreeg opeens op mijn mac constant overal reclame. Terwijl alles al 2-3 jaar stabiel draait op mijn pi.
Ik ging eens kijken naar de DNS in de mac (dacht eerst aan een apple relay omdat ik dat als " whitelist". in de Pi hole vond.
Uiteindelijk stonden er dus 2 DNS adressen ingevuld in de unifi omgeving.
Dit veranderd naar alleen een primary en alles werkt weer zoals het is.

Dit bewijst soort van ook weer dan als een device besloten heeft dat de secondary sneller is of wat dan ook dat een single DNS beter werkt. Tenzij die uitvalt. Dan moet ik thuis in de router aan de slag.
Of inderdaad een 2e Pihole als secondary.

Ik bedenk met net opeens dat ik de DNS cache ook geflusht heb. Dus dan had hij wellicht ook weer naar de primary gekeken.

Dat is inderdaad hoe een OS werkt. Het checked hoe dns is ingesteld. Als meer dan 1 dan checked het welke het snelste reageerd en gaat vervolgens, tot een herstart, deze gebruiken (of tot de ander bewezen heeft sneller te zijn). Als je dus twee verschillende pi's hebt dan forceer je het os dus om 1 van de twee dns servers te kiezen. Bij windows 11 is het iig geval dat wanneer beide pi's onbereikbaar zijn dat deze dan niet zelf een dns server gaat verzinnen. Gelukkig

[deHakkelaar]

Nogmaals, 8.8.8.8 wordt helemaal niet geblokkeerd door die nieuwe v6 DHCP DNS instelling.

En wbt primary & secondary DNS, die bestaan niet voor een boel client DNS implementaties.
Voor deze clients is dit gewoon een lijst met DNS servers.
EDIT: Voor de meeste Linux distros worden ze ook niet aangegeven als primary, secondary etc maar is het gewoon een lijst.
Windows pikt de snelst reageerende net zoals veel Linux implementaties,
sommigen doen round robin,
en sommigen hanteren wel alleen de primary eerst en bij geen antwoord naar de secondary (strickt order).
En Pi-hole zelf doet dit "Improve detection algorithm ...":
https://docs.pi-hole.net/...-best-forward-destination

[ Voor 10% gewijzigd door deHakkelaar op 23-12-2023 18:03 ]

[nero355]

ViezeVis schreef op vrijdag 22 december 2023 @ 21:20:
Hebben jullie in jullie routers nu ook dezelfde Primary en Secundary IP van PiHole?

4 keer zelfs

Leek mij wel logisch omdat PiHole de DNS weer verdeelt aan CloudFlare dns.

Heeft daar niks mee te maken, maar wel dus het probleem dat Google en Amazon of Apple apparaten slimmer dan ik denken te zijn!

bibi2205 schreef op vrijdag 22 december 2023 @ 22:17:
In je router moet je enkel als primaire DNS het adres van je Pihole ingeven.

NOPE.AVI

dss58 schreef op vrijdag 22 december 2023 @ 23:28:
ik heb 2 raspberry pi's als pihole, primary wijst naar de eerste, secondary DNS naar de andere, krijg je leuk inzicht tussen die 2

Volgens mij had jij het een keer over een 80%/20% verdeling ongeveer ??

deHakkelaar schreef op zaterdag 23 december 2023 @ 00:27:
Het is zelfs wenselijk om het Pi-hole IP meerdere keren op te voeren voor DNS in de LAN DHCP service sectie vd router.
Voor de nieuwe Pi-hole versie 6 (nog in Beta) is dit zelfs de default als je Pi-hole's eigen DHCP service toepast:
[Afbeelding]

SEXY !!!

deHakkelaar schreef op zaterdag 23 december 2023 @ 00:46:
Apparaten waarvan ik weet dat ze bugged zijn met dat 8.8.8.8 DNS IP zijn Oneplus, Oppo en ik geloof ook Ooma.

Maak daar maar alle Android Google apparaten van hoor!

Daarom draait mijn OnePlus 7 Pro nu gewoon lekker Ubuntu Touch

Airw0lf schreef op zaterdag 23 december 2023 @ 08:11:
Mwah - ik gok dat het een "bewuste" keuze doordat ze iets doen met een Google OS.

Tis te zeggen... ik heb het nogal eens meegemaakt dat als je dat soort apparaten de mogelijkheid ontneemt om de welbekende 8.8.8.8 te gebruiken, dan doen ze het niet - want "geen" internet.

En als je die DNAT/SNAT en doet alsof je Pi-Hole 8.8.8.8 dan wel 8.8.4.4 is

Dus ik hoop voor het pihole support team dat ze dit niet als default gaan inzetten.

Juist wel joh!

Scheelt een hoop berichten in de trant van "Pi-Hole not blocking ads ?!"

87Vortex87 schreef op zaterdag 23 december 2023 @ 10:15:
Ik draai Pihole met een aantal lijsten die in totaal ongeveer 1 miljoen domeinen blokkeert.

Als je hulp wilt dan moet je ons wel vertellen welke dat dan zijn hé !!

deHakkelaar schreef op zaterdag 23 december 2023 @ 11:04:
Het is heel simpel.
Als deze apparaten maar 1 DNS server krijgen aangeboden via DHCP, dan voegen ze automatisch 8.8.8.8 toe aan het DNS server lijstje.
Als ze er 2 of meerderen krijgen aangeboden, dan voegen ze niet 8.8.8.8 toe.

Voor zover ik weet moet je minimaal 3 keer je eigen DNS aanbieden om het te overschrijven

Het is de meest idiote DNS implementatie die ik ken net zoals dat Asus routers altijd hun eigen IP mee adverteerden als je een DNS server opvoerde in de DHCP service instellingen.
Dat gaat gewoon nooit goed werken omdat de DNS implementatie vd client helemaal niet verhindert dat de client die "andere" DNS server aanspreekt en dus je lokale DNS records niet oplossen omdat die andere, zoals bv 8.8.8.8, er niet vanaf weet.

ASUS Tjonge jonge jonge...

Als iemand een goede verklaring heeft waarom die apparaten dit doen hoor ik die graag?

Because dumbass fabrikanten en in het geval van Google pure Spyware crap!

Ps. voor die Oneplus en Oppo clients is al aangetoond dat het geen nadelige gevolgen heeft als je meerdere keren hetzelfde IP via DHCP adverteert.

Eigenlijk alle Android telefoons en tablets inderdaad

Airw0lf schreef op zaterdag 23 december 2023 @ 11:51:
Ik heb de nodig Google-OS achtige voorbij zien komen die niet meer werkte als ze 4 DNS servers kregen - maakte niet uit of het 4 dezelfde waren of 4 verschillende. Blijkbaar was er geen ruimte meer voor de beroemde 8.8.8.8. Met als resultaat de melding "no internet" (o.i.d.).

Vanaf dat moment waren veel functies stuk - die gingen spontaan werken als je tenminste één DNS server entry weghaalde.

Wat een troep!

Zouden bij mij meteen weer richting de fabrikant gaan!

ApC_IcE schreef op zaterdag 23 december 2023 @ 13:15:
Ik kreeg opeens op mijn mac constant overal reclame. Terwijl alles al 2-3 jaar stabiel draait op mijn pi.
Ik ging eens kijken naar de DNS in de mac (dacht eerst aan een apple relay omdat ik dat als " whitelist". in de Pi hole vond.
Uiteindelijk stonden er dus 2 DNS adressen ingevuld in de unifi omgeving.
Dit veranderd naar alleen een primary en alles werkt weer zoals het is.

Ik heb er hier dus 4 en nog nooit van Apple gebruikende gasten gehoord dat ze problemen hadden met de WiFi

Ik heb wel een probleem met hen :
- Random MAC Address onzin
- Geef de telefoon toegang en de tablet heeft hem opeens ook!

Gauw geleerd om dat meteen te voorkomen als ze er net zijn!

Raymond P schreef op zaterdag 23 december 2023 @ 13:17:
Er zijn wel een paar devices van Google die niet (goed) meer werken als ze 8.8.8.8 niet transparant kunnen bereiken. Voornamelijk spul uit de Nest familie.
Andoid devices volgen hier 100% de opgegeven DNS server(s).

M'n Nest Hub (fuchsia OS) is het meest vervuilend en kritisch. Maareh, die queries naar 8.8.8.8 (en ipv6 tegenhangers) worden hier ook gewoon door mijn servertje beantwoord.

En als je die DNAT/SNAT

Airw0lf schreef op zaterdag 23 december 2023 @ 13:45:
Ik weet niet waar die apparaatjes precies op draaide - waren van die Google Home dingen.
Ik dacht van Lenovo en van Google zelf.

Opzich wel een mooie straf voor het gebruik van die Spyware

Webgnome schreef op zaterdag 23 december 2023 @ 13:48:
Bij windows 11 is het iig geval dat wanneer beide pi's onbereikbaar zijn dat deze dan niet zelf een dns server gaat verzinnen. Gelukkig.

Hey kijk! Iets positiefs over Windows 11

/Flauw

Webgnome schreef op zaterdag 23 december 2023 @ 16:32:
Mijn ervaring is vooral met windows. Officieel, dacht ik, dat het via round-robin gaat maar dat is 9 van de 10 x gewoon de eerste.
En zoals ik al schreef, als de bovenste iets te lang tijd nodig heeft dan switch windows naar de tweede.

Je moet eens één van de twee down gooien en dan opnieuw testen : Leverde mij DNS Time-Outs op in het verleden!

bibi2205 schreef op zaterdag 23 december 2023 @ 16:52:
Dat is niet hoe DHCP werkt, het (Apple) apparaat vraagt aan je fritzbox welk IP hij mag gebruiken...
Klinkt eerder alsof de DHCP tabel in de fritzbox in de war was geraakt door een verlopen lease oid.

Maargoed, we gaan offtopic en ik heb niet de indruk dat het veel zin heeft om er verder op in te gaan aangezien je de schuld liever bij Apple legt.

Hoe graag ik ook die Fritz! de schuld geef (want echt een hekel aan in meerdere opzichten en zo) heb ik toch ook wel zo mijn twijfels over een Apple apparaat op het moment dat die niet mag functioneren zoals die graag zou willen !!

Apple/Google/Microsoft en eigenlijk ook wel die dingen van Amazon en dergelijken = Gewoon niet te vertrouwen!

alex3305 schreef op zaterdag 23 december 2023 @ 16:52:
@deHakkelaar @Airw0lf Toevallig had ik dezelfde discussie omtrent Google en de DNS servers in het [Adguard Home] Ervaringen & discussie topic. Eerder, ik weet niet of het nog zo is, werkte bijvoorbeeld de HomeWizard app ook niet als je 8.8.8.8 blokkeert omdat deze gebruikt werd om te controleren of internettoegang werkte .

En als je die DNAT/SNAT richting je eigen Pi-Hole

[Toet3r]

Oke, bij deze mijn eerste bevindingen van Orbital-Sync

Voor de niet docker gebruikers onder ons, ik heb helaas niet kunnen vinden dat orbital-sync te gebruiken is zonder docker. gravity-sync is misschien een alternatief.
Of orbital-sync om te bouwen is naar een niet docker versie kan ik zo niet zeggen, hiervoor heb ik te weinig programmeer kennis. Iemand anders misschien die het project op github kan bekijken en hier meer over kan zeggen?

Ik zag op docker hub dat de laatste update 9 maanden geleden was, heb geen idee of de docker image nog wordt bijgehouden. Orbital-sync met pihole 6.0 zal mogelijk dus niet (goed) werken. Zo is er geen environment variable voor subscribed allowlists omdat dit een nieuwe functie is in pihole 6.0. Zo zullen er ook verschillen zitten in de databases van pihole 5.x en 6.0 die waarschijnlijk errors gaan opleveren bij syncen tussen deze versies.

In docker compose file heb je een primary instantie aangeduid met (PRIMARY_HOST_BASE_URL) en 1 of meerdere secondary aangeduid met (SECONDARY_HOST_X_BASE_URL). Het lijkt dat je zo ongeveer een oneindig aantal pihole instanties kan toevoegen. Belangrijk is hierbij wel dat je in je docker-compose file de nummers opeenvolgend houd dus (SECONDARY_HOST_1_BASE_URL, SECONDARY_HOST_2_BASE_URL, etc). Als hier een nummer in wordt overgeslagen worden alles instanties na het gat geskipped. Alles wordt vervolgens van de primary naar alle secondary's gekopieerd.
Je kan bij de environment variables aangeven welke dingen wel of niet gekopieerd moeten worden, adlists, groups, clients enz. zo kan je bijvoorbeeld wel alle adlists syncen maar niet de whitelisted domains. stel je wilt een verschil maken tussen trusted clients op de ene pihole en guest clients op een andere pihole. Ook is er de mogelijkheid om een notificatie toe te voegen bij slagen/falen van sync.

Wat betreft test van orbital sync. Ik heb een simpele test uitgevoerd met 2 schone instanties van pihole (docker tag 2023.11.0) In de eerste heb ik meerdere blocklists (oisd, firebog), een paar whitelist domains, een groep en een client toegevoegd. Deze lijken allemaal goed te zijn gekopieerd naar de 2e instantie van pihole.

Op de github pagina valt dit alles ook te lezen en staat een voorbeeld voor in docker-compose file.

Mocht ik nog nieuwe bevindingen hebben laat ik het weten.

Veel success

[dss58]

Toet3r schreef op dinsdag 26 december 2023 @ 23:32:
Oke, bij deze mijn eerste bevindingen van Orbital-Sync

Voor de niet docker gebruikers onder ons, ik heb helaas niet kunnen vinden dat orabital-sync te gebruiken is zonder docker. gravity-sync is misschien een alternatief.
Of orbital-sync om te bouwen is naar een niet docker versie kan ik zo niet zeggen, hiervoor heb ik te weinig programmeer kennis. Iemand anders misschien die het project op github kan bekijken en hier meer over kan zeggen?

Ik zag op docker hub dat de laatste update 9 maanden geleden was, heb geen idee of de docker image nog wordt bijgehouden. Orbital-sync met pihole 6.0 zal mogelijk dus niet (goed) werken. Zo is er geen environment variable voor subscribed allowlists omdat dit een nieuwe functie is in pihole 6.0. Zo zullen er ook verschillen zitten in de databases van pihole 5.x en 6.0 die waarschijnlijk errors gaan opleveren bij syncen tussen deze versies.

In docker compose file heb je een primary instantie aangeduid met (PRIMARY_HOST_BASE_URL) en 1 of meerdere secondary aangeduid met (SECONDARY_HOST_X_BASE_URL). Het lijkt dat je zo ongeveer een oneindig aantal pihole instanties kan toevoegen. Belangrijk is hierbij wel dat je in je docker-compose file de nummers opeenvolgend houd dus (SECONDARY_HOST_1_BASE_URL, SECONDARY_HOST_2_BASE_URL, etc). Als hier een nummer in wordt overgeslagen worden alles instanties na het gat geskipped. Alles wordt vervolgens van de primary naar alle secondary's gekopieerd.
Je kan bij de environment variables aangeven welke dingen wel of niet gekopieerd moeten worden, adlists, groups, clients enz. zo kan je bijvoorbeeld wel alle adlists syncen maar niet de whitelisted domains. stel je wilt een verschil maken tussen trusted clients op de ene pihole en guest clients op een andere pihole. Ook is er de mogelijkheid om een notificatie toe te voegen bij slagen/falen van sync.

Wat betreft test van orbital sync. Ik heb een simpele test uitgevoerd met 2 schone instanties van pihole (docker tag 2023.11.0) In de eerste heb ik meerdere blocklists (oisd, firebog), een paar whitelist domains, een groep en een client toegevoegd. Deze lijken allemaal goed te zijn gekopieerd naar de 2e instantie van pihole.

Op de github pagina valt dit alles ook te lezen en staat een voorbeeld voor in docker-compose file.

Mocht ik nog nieuwe bevindingen hebben laat ik het weten.

Veel success

dank voor je speurwerk man, ik ga is naar gravitiy sync kijken, tnx !!!

[mrdemc]

Toet3r schreef op dinsdag 26 december 2023 @ 23:32:
Oke, bij deze mijn eerste bevindingen van Orbital-Sync

Voor de niet docker gebruikers onder ons, ik heb helaas niet kunnen vinden dat orbital-sync te gebruiken is zonder docker. gravity-sync is misschien een alternatief.
Of orbital-sync om te bouwen is naar een niet docker versie kan ik zo niet zeggen, hiervoor heb ik te weinig programmeer kennis. Iemand anders misschien die het project op github kan bekijken en hier meer over kan zeggen?

Ik zag op docker hub dat de laatste update 9 maanden geleden was, heb geen idee of de docker image nog wordt bijgehouden. Orbital-sync met pihole 6.0 zal mogelijk dus niet (goed) werken. Zo is er geen environment variable voor subscribed allowlists omdat dit een nieuwe functie is in pihole 6.0. Zo zullen er ook verschillen zitten in de databases van pihole 5.x en 6.0 die waarschijnlijk errors gaan opleveren bij syncen tussen deze versies.

In docker compose file heb je een primary instantie aangeduid met (PRIMARY_HOST_BASE_URL) en 1 of meerdere secondary aangeduid met (SECONDARY_HOST_X_BASE_URL). Het lijkt dat je zo ongeveer een oneindig aantal pihole instanties kan toevoegen. Belangrijk is hierbij wel dat je in je docker-compose file de nummers opeenvolgend houd dus (SECONDARY_HOST_1_BASE_URL, SECONDARY_HOST_2_BASE_URL, etc). Als hier een nummer in wordt overgeslagen worden alles instanties na het gat geskipped. Alles wordt vervolgens van de primary naar alle secondary's gekopieerd.
Je kan bij de environment variables aangeven welke dingen wel of niet gekopieerd moeten worden, adlists, groups, clients enz. zo kan je bijvoorbeeld wel alle adlists syncen maar niet de whitelisted domains. stel je wilt een verschil maken tussen trusted clients op de ene pihole en guest clients op een andere pihole. Ook is er de mogelijkheid om een notificatie toe te voegen bij slagen/falen van sync.

Wat betreft test van orbital sync. Ik heb een simpele test uitgevoerd met 2 schone instanties van pihole (docker tag 2023.11.0) In de eerste heb ik meerdere blocklists (oisd, firebog), een paar whitelist domains, een groep en een client toegevoegd. Deze lijken allemaal goed te zijn gekopieerd naar de 2e instantie van pihole.

Op de github pagina valt dit alles ook te lezen en staat een voorbeeld voor in docker-compose file.

Mocht ik nog nieuwe bevindingen hebben laat ik het weten.

Veel success

In de readme op de GitHub pagina die je linkt staat onder de Docker uitleg een Node uitleg. Als je dus een VM of gewone machine hebt kun je daar node op installeren en zou je het gewoon moeten kunnen gebruiken zonder docker via de NPM package manager van Node met de juiste env waarden ingesteld.

[deHakkelaar]

Toet3r schreef op maandag 18 maart 2024 @ 10:17:
Voor het resultaat, gebruik het commando:

ip -br -4 a

In mijn geval is dit dit

code:

lo               UNKNOWN        127.0.0.1/8
eth0             UP             192.168.1.5/24
vlan20@eth0      UP             192.168.20.254/24
vlan30@eth0      UP             192.168.30.254/24

Asl je die lo interface wilt uitsluiten in het lijstje:

code:

ip -br -4 addr show scope global

EDIT: Ter info:

$ ip -br -4 addr show help
[..]
       ip address [ show [ dev IFNAME ] [ scope SCOPE-ID ] [ master DEVICE ]
[..]
SCOPE-ID := [ host | link | global | NUMBER ]

EDIT2: Ow handige tip, met TAB TAB kom je ook een heel end:

$ ip -br -4
address     help        link        mptcp       neighbour   ntable      sr          tunnel
addrlabel   ila         macsec      mroute      netconf     ntbl        tap         tuntap
amt         ioam        maddress    mrule       netns       route       tcpmetrics  vrf
fou         l2tp        monitor     neighbor    nexthop     rule        token       xfrm

$ ip -br -4 address
add      change   del      flush    help     replace  show

$ ip -br -4 address show
dadfailed   dev         eth0        lo          primary     secondary   tentative   up
deprecated  dynamic     label       permanent   scope       temporary   to

$ ip -br -4 address show scope
global   host     link     nowhere  site

Als onder is geinstaleerd:

$ apt show bash-completion
[..]
Description: programmable completion for the bash shell
 bash completion extends bash's standard completion behavior to achieve
 complex command lines with just a few keystrokes.  This project was
 conceived to produce programmable completion routines for the most
 common Linux/UNIX commands, reducing the amount of typing sysadmins
 and programmers need to do on a daily basis.

[ Voor 64% gewijzigd door deHakkelaar op 18-03-2024 20:06 ]

[geenwindows]

Diedo70 schreef op vrijdag 18 april 2025 @ 22:00:
[...]
Zelf ip adres van DNS server kan toch wel in deze nieuwe interface lijkt het:
[Afbeelding]
primary DNSv4 en DNSv6 heb ik nu de IPs van de pihole ingevuld (al geeft de pihole 2 ipv6 adressen aan bij de system tab)
[...]

die fe80:: adres moet je niet hebben, je moet de andere gebruiken. met dat adres kun je ook pihole webgui op bereiken met [ ] ( [ipv6 adres]/admin/login )
en zoals W1ck1e ook al aangaf, als je secondary adres niet pi-hole is, word pi-hole niet altijd gebruikt.
die 195.121.1.66 is een KPN DNS server.