[Pi-Hole] Ervaringen & discussie

[deHakkelaar]

nero355 schreef op zondag 10 januari 2021 @ 18:33:
Het zou mooi zijn als je de TTL van lokale records lekker hoog kan zetten, want die blijven bij de meesten van ons denk ik toch wel altijd hetzelfde, want Static IP of Static DHCP Mapping

@deHakkelaar
Enige kans dat er ooit zo'n optie erbij komt

Die optie is er al, alleen niet via de GUI (Local DNS records) of via de /etc/hosts file.
Alles wat je via de GUI aanmaakt, toevoegt aan de /etc/hosts file, of de domeinen die op de blocklists staan zullen de TTL aannemen geconfigureerd in onderstaande bestandje:

pi@ph5:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
local-ttl=2
[..]

pi@ph5:~ $ dig +noall +answer @localhost a flurry.com
flurry.com.             2       IN      A       0.0.0.0

pi@ph5:~ $ dig +noall +answer @localhost a nas
nas.                    2       IN      A       10.0.0.3

Domeinen die moeten worden ge-forward upstream zullen gewoon de TTL aannemen afkomstig van de "authoritative " DNS server(s):

pi@ph5:~ $ dig +noall +answer @localhost soa tweakers.net
tweakers.net.           3600    IN      SOA     tweakdns.nl. dns.tweakers.net. 2020073007 3600 3600 2419200 3600

pi@ph5:~ $ dig +noall +answer @tweakdns.nl a tweakers.net
tweakers.net.           60      IN      A       213.239.154.30

pi@ph5:~ $ dig +noall +answer @localhost a tweakers.net
tweakers.net.           60      IN      A       213.239.154.30

Die korte TTL is zoals je mischien al wist gekozen zodat gebruikers meteen reultaat hebben als ze wat wijzigen en de clients niet hoeven te wachten totdat de TTL is verstreken.
Die TTL kan soms zelfs zo hoog ingesteld staan als 12 of 24 uur.
Wil je zelf controle hebben over de TTL van bepaalde records, zul je zelf een bestandje moeten aanmaken in de /etc/dnsmasq.d folder met onderstaande "directive":

pi@ph5:~ $ man dnsmasq
[..]
       --host-record=<name>[,<name>....],[<IPv4-address>],[<IPv6-ad‐
       dress>][,<TTL>]
              Add  A,  AAAA and PTR records to the DNS. This adds one or
              more names to the DNS with associated IPv4  (A)  and  IPv6
              (AAAA) records. A name may appear in more than one --host-
              record and therefore be assigned more  than  one  address.
              Only  the  first  address creates a PTR record linking the
              address to the name. This is the  same  rule  as  is  used
              reading hosts-files.  --host-record options are considered
              to be read before host-files, so a  name  appearing  there
              inhibits  PTR-record  creation if it appears in hosts-file
              also. Unlike hosts-files, names  are  not  expanded,  even
              when --expand-hosts is in effect. Short and long names may
              appear in the same --host-record, eg.   --host-record=lap‐
              top,laptop.thekelleys.org,192.168.0.1,1234::100

              If  the  time-to-live  is given, it overrides the default,
              which is zero or the value of --local-ttl. The value is  a
              positive integer and gives the time-to-live in seconds.

EDIT: foutje SOA lookup ipv NS lookup voor authoritative DSN server(s)

[ Voor 3% gewijzigd door deHakkelaar op 11-01-2021 09:51 ]

[ed1703]

deHakkelaar schreef op maandag 11 januari 2021 @ 06:25:
[...]

Die optie is er al, alleen niet via de GUI (Local DNS records) of via de /etc/hosts file.

Het punt is juist dat dit beschikbaar zou moeten zijn in de web interface, want die records heb je al. Je wilt juist niet met een pihole in een ha opstelling allerlei aanpassingen moeten doen. Voordeel is namelijk dat pihole sync ook direct out of the box werkt, want die download alles hosts in csv file. Het niet kunnen zetten van een TTL op hosts is afgezien van de logica door hoe het GitHub project er naar kijkt nogal krom en veroorzaakt onnodig veel requests.

[deHakkelaar]

@ed1703 Ik ben het met je eens grootendeels.
Ze hebben besloten om de "Local DNS records" in een hosts formaat bestandje op te slaan waar geen TTL kan worden meegegeven:

pi@ph5:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
addn-hosts=/etc/pihole/custom.list
[..]

pi@ph5:~ $ cat /etc/pihole/custom.list
10.0.0.1 router
10.0.0.3 nas
10.0.0.9 avr
10.0.0.2 noads

Willen ze dat omgooien dan zullen ze die host-record= directive moeten gaan gebruiken.
Maak een "feature request" aan of doe zelf een pull op github zou ik zeggen

EDIT: Ow en als je toch een feature request aanmaakt, vraag dan meteen ook om al die andere
Wikipedia: List of DNS record types

[ Voor 25% gewijzigd door deHakkelaar op 11-01-2021 11:58 ]

[Hann1BaL]

Na het instellen van 2x Pi-Hole zie ik ineens een client die bij beide Pi-Holes zeer veel requests doet (13500 sinds gisteren)
Allemaal NTP gerelateerd zo lijkt.

Maar alle clients zijn de interne IPs, maar deze wordt weergegeven als: (xxx = mijn publieke IP van Ziggo)
xxx-xxx-xxx-xxx.cable.dynamic.v4.ziggo.nl

Zou dit dan het modem zijn? Maar zou die niet als client met het interne IP weergegeven moeten worden? (Mijn Ziggo modem doet de DHCP; staat niet in bridge)

Dit lijkt toch niet te kloppen.
Totaal dus rond de 27000 NTP server aanvragen in 24 uur? Dat is 1 aanvraag per 3 sec....

Nooit eerder gezien op mijn PiHole(s)

EDIT: het komt overeen met de 3 NTP servers die ook weergegeven worden in mn Modem/router van Ziggo. Het is dus wel zeker dat deze de aanvragen doet, maar waarom elke 3 sec is dan de grote vraag.

EDIT2:
Als je het niet kunt achterhalen herstart je de boel gewoon.
Nu een succesvolle NTP sync en aanvragen zijn gedropped. Lang leve de crappy modems van Ziggo.

[ Voor 22% gewijzigd door Hann1BaL op 11-01-2021 16:27 ]

[ed1703]

deHakkelaar schreef op maandag 11 januari 2021 @ 07:15:
@ed1703 Ik ben het met je eens grootendeels.
Ze hebben besloten om de "Local DNS records" in een hosts formaat bestandje op te slaan waar geen TTL kan worden meegegeven:

pi@ph5:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
addn-hosts=/etc/pihole/custom.list
[..]

pi@ph5:~ $ cat /etc/pihole/custom.list
10.0.0.1 router
10.0.0.3 nas
10.0.0.9 avr
10.0.0.2 noads

Willen ze dat omgooien dan zullen ze die host-record= directive moeten gaan gebruiken.
Maak een "feature request" aan of doe zelf een pull op github zou ik zeggen

EDIT: Ow en als je toch een feature request aanmaakt, vraag dan meteen ook om al die andere
Wikipedia: List of DNS record types

Neem alleen aan dat niemand een pihole voor het compleet beschikbaar maken van een domein op het internet gebruikt? Een CAA lijkt mij dan al een nutteloos iets.

[deHakkelaar]

ed1703 schreef op maandag 11 januari 2021 @ 17:02:
[...]

Neem alleen aan dat niemand een pihole voor het compleet beschikbaar maken van een domein op het internet gebruikt? Een CAA lijkt mij dan al een nutteloos iets.

dnsmasq ondersteund ze niet allemaal.
Maar onderstaande kunnen ook bruikbaar zijn in je eigen LAN:

pi@ph5:~ $ man dnsmasq
[..]
       -m, --mx-host=<mx name>[[,<hostname>],<preference>]
              Return  an  MX  record  named  <mx name> pointing to the
              given hostname (if given), or the host specified in  the
              --mx-target  switch or, if that switch is not given, the
              host on which dnsmasq is running. The default is  useful
              for  directing  mail  from systems on a LAN to a central
              server. The preference value is optional,  and  defaults
              to  1 if not given. More than one MX record may be given
              for a host.
[..]
       -W,             --srv-host=<_service>.<_prot>.[<domain>],[<tar‐
       get>[,<port>[,<priority>[,<weight>]]]]
              Return a SRV DNS record. See RFC2782 for details. If not
              supplied, the domain defaults to that given by --domain.
              The default for the target domain is empty, and the  de‐
              fault  for  port  is one and the defaults for weight and
              priority are zero. Be careful if transposing  data  from
              BIND  zone  files: the port, weight and priority numbers
              are in a different order. More than one SRV record for a
              given  service/domain is allowed, all that match are re‐
              turned.
[..]
       --host-record=<name>[,<name>....],[<IPv4-address>],[<IPv6-ad‐
       dress>][,<TTL>]
              Add A, AAAA and PTR records to the DNS. This adds one or
              more names to the DNS with associated IPv4 (A) and  IPv6
              (AAAA)  records.  A  name  may  appear  in more than one
              --host-record and therefore be assigned  more  than  one
              address.
[..]
       -Y, --txt-record=<name>[[,<text>],<text>]
              Return  a  TXT  DNS record. The value of TXT record is a
              set of strings, so  any number may be  included,  delim‐
              ited  by commas; use quotes to put commas into a string.
              Note that the maximum length of a single string  is  255
              characters,  longer strings are split into 255 character
              chunks.
[..]
       --ptr-record=<name>[,<target>]
              Return a PTR DNS record.
[..]
       --cname=<cname>,[<cname>,]<target>[,<TTL>]
              Return  a  CNAME  record which indicates that <cname> is
              really <target>.

[MOmax]

De Pi-Hole draait nu een week. Sinds gisteren heb ik de DHCP server van de Pi-Hole aangezet en die van de Fritz.box uit; voornamelijk om zicht te hebben op de clients. Dat is op zich gelukt, maar één client springt eruit met >1M hits, namelijk de Fritz.box zelf.
Andere clients 30.000 of minder.
Heeft iemand hier ervaring mee? Een verklaring? Oplossing? Query’s lopen vast op dit aantal, lijkt t.

[Eärendil]

Zijn er misschien clients die de Fritzbox als DNS-server gebruiken?

[asing]

Voor degenen die CloudFlared op hun Pi Hole hebben draaien en vanmiddag ineens amper konden internetten, 1.1.1.1 had een storing. 1.0.0.1 doet het wel.

[MOmax]

Eärendil schreef op woensdag 13 januari 2021 @ 19:04:
Zijn er misschien clients die de Fritzbox als DNS-server gebruiken?

Nou nee, hooguit een Solcon media player.

Ik heb de FritzBox nu in een gedisablede group gestopt.

[ Voor 11% gewijzigd door MOmax op 13-01-2021 19:17 ]

[deHakkelaar]

MOmax schreef op woensdag 13 januari 2021 @ 18:20:
De Pi-Hole draait nu een week. Sinds gisteren heb ik de DHCP server van de Pi-Hole aangezet en die van de Fritz.box uit; voornamelijk om zicht te hebben op de clients. Dat is op zich gelukt, maar één client springt eruit met >1M hits, namelijk de Fritz.box zelf.
Andere clients 30.000 of minder.
Heeft iemand hier ervaring mee? Een verklaring? Oplossing? Query’s lopen vast op dit aantal, lijkt t.

Mogelijk een "DNS forwarding loop" of partial loop.
Wat zijn je upstream DNS servers in Pi-hole ?

code:

dig +short @localhost chaos txt servers.bind

[nero355]

asing schreef op woensdag 13 januari 2021 @ 19:14:
Voor degenen die CloudFlared op hun Pi Hole hebben draaien en vanmiddag ineens amper konden internetten, 1.1.1.1 had een storing. 1.0.0.1 doet het wel.

Daarom : Unbound FTW!!!

[asing]

nero355 schreef op vrijdag 15 januari 2021 @ 01:15:
[...]

Daarom : Unbound FTW!!!

Unbound is leuk maar niet versleuteld. Mijn provider hoeft niet te weten waar ik allemaal heen ga. Het wachten is op ESNI, dan zien ze echt niets meer.

Mijn oplossing was om mijn firewall weer even op te geven als 2e DNS server.

[GieltjE]

asing schreef op vrijdag 15 januari 2021 @ 10:30:
[...]

Unbound is leuk maar niet versleuteld. Mijn provider hoeft niet te weten waar ik allemaal heen ga. Het wachten is op ESNI, dan zien ze echt niets meer.

Mijn oplossing was om mijn firewall weer even op te geven als 2e DNS server.

Liever dat mijn provider moeite moet doen om mijn verkeer te onderscheppen en te verwerken als dat het direct naar amazon's log files gaat

[MOmax]

deHakkelaar schreef op donderdag 14 januari 2021 @ 16:03:
[...]

Mogelijk een "DNS forwarding loop" of partial loop.
Wat zijn je upstream DNS servers in Pi-hole ?

code:

dig +short @localhost chaos txt servers.bind

Daar komt uit:

Router + OpenDNS (2x)
"192.168.178.1#53 12 0" "208.67.220.220#53 1697 215" "208.67.222.222#53 1359 141"

[asing]

GieltjE schreef op vrijdag 15 januari 2021 @ 11:13:
[...]


Liever dat mijn provider moeite moet doen om mijn verkeer te onderscheppen en te verwerken als dat het direct naar amazon's log files gaat

Bij mijn weten is Cloudflare geen onderdeel van Amazon, maar ik kan het mis hebben.

[deHakkelaar]

MOmax schreef op vrijdag 15 januari 2021 @ 11:28:
Daar komt uit:

Router + OpenDNS (2x)
"192.168.178.1#53 12 0" "208.67.220.220#53 1697 215" "208.67.222.222#53 1359 141"

Als Pi-hole de router IP gebruikt upstream, en de router Pi-hole gebruikt upstream, kunnen queries gevangen worden in een loop zonder einde.
Ik neem aan dat je "Conditional forwarding" (CF) in Pi-hole hebt ingesteld met dat 192.168.178.1 router IP ?

code:

grep rev-server= -R /etc/dnsmasq.*

CF heb je niet nodig als Pi-hole DHCP doet dus ik zou die setting uitschakelen en kijken ofdat je dan nog steeds zoveel queries hebt ?

[deHakkelaar]

asing schreef op vrijdag 15 januari 2021 @ 10:30:
[...]
Unbound is leuk maar niet versleuteld. Mijn provider hoeft niet te weten waar ik allemaal heen ga. Het wachten is op ESNI, dan zien ze echt niets meer.

Mijn oplossing was om mijn firewall weer even op te geven als 2e DNS server.

Daar zijn al vele discussies over geweest op Pi-hole Discourse.
De algemene consensus is toch dat een recursive DNS server zoals Unbound meer privacy bied als dat je al je DNS queries by Cloudflare neerlegt.

[asing]

deHakkelaar schreef op vrijdag 15 januari 2021 @ 14:29:
[...]

Daar zijn al vele discussies over geweest op Pi-hole Discourse.
De algemene consensus is toch dat een recursive DNS server zoals Unbound meer privacy bied als dat je al je DNS queries by Cloudflare neerlegt.

Ik snap dat er discussie is, en de vraag is voor wie je je wilt "verstoppen". Ik zal de discussie niet hier oprakelen maar ik heb na een hoop inleeswerk besloten lekker bij CloudFlared te blijven.

[deHakkelaar]

asing schreef op vrijdag 15 januari 2021 @ 14:37:
[...]

Ik snap dat er discussie is, en de vraag is voor wie je je wilt "verstoppen". Ik zal de discussie niet hier oprakelen maar ik heb na een hoop inleeswerk besloten lekker bij CloudFlared te blijven.

Dat is je goed recht.
En ESNI is eigenlijk alleen browser/HTTPS ge-orienteerd.
ESNI werkt niet voor andere protocollen zoals bv mail of FTP etc ... nog.

[MOmax]

deHakkelaar schreef op vrijdag 15 januari 2021 @ 14:14:
[...]
CF heb je niet nodig als Pi-hole DHCP doet dus ik zou die setting uitschakelen en kijken ofdat je dan nog steeds zoveel queries hebt ?

Klopt, daar moet het probleem gezeten hebben. CF staat nu uit en router als DNS is weg. Probleem lijkt daarmee verholpen te zijn.

[Arjan1986]

Pi-hole Core v5.2.3, Web v5.3 and FTL v5.4 released!
https://discourse.pi-hole...d-ftl-v5-4-released/43009

[ Voor 23% gewijzigd door Arjan1986 op 15-01-2021 22:12 ]

[DoeEensGek]

Vraagje, hebben jullie weleens last dat een website niet laad? Gewoon een gebruikelijke website zoals tweakers.net. Het duurt dan oneindig lang met uiteindelijk een foutmelding dat de website niet bestaat. Maar een simpele f5 en binnen no-time is de pagina beschikbaar.
Ik probeer uit te vogelen of dit aan pihole ligt. Heb het ook met mijn telefoon waarin apps gewoon of de browser oneindig aan het wachten is.

[The Druid]

DoeEensGek schreef op zaterdag 16 januari 2021 @ 11:38:
Vraagje, hebben jullie weleens last dat een website niet laad? Gewoon een gebruikelijke website zoals tweakers.net. Het duurt dan oneindig lang met uiteindelijk een foutmelding dat de website niet bestaat. Maar een simpele f5 en binnen no-time is de pagina beschikbaar.
Ik probeer uit te vogelen of dit aan pihole ligt. Heb het ook met mijn telefoon waarin apps gewoon of de browser oneindig aan het wachten is.

Unbound ook draaien, zo ja dan de configuration file /etc/dnsmasq.d/01-pihole.conf bewerken en de cache-size=1000 aanpassen naar 0. Tevens in de webinterface Use DNSSEC niet aan vinken.

[Hulliee]

The Druid schreef op zaterdag 16 januari 2021 @ 12:07:
[...]


Unbound ook draaien, zo ja dan de configuration file /etc/dnsmasq.d/01-pihole.conf bewerken en de cache-size=1000 aanpassen naar 0. Tevens in de webinterface Use DNSSEC niet aan vinken.

Ik zou dat in een aparte .conf file zetten want de 01-pihole.conf wordt bij een update overschreven.

Verder is het advies:
https://discourse.pi-hole...abled-or-disabled/27150/3

Pi-Hole cache enable
Pihole DNSSEC disable

[ Voor 17% gewijzigd door Hulliee op 16-01-2021 12:21 ]

[jpgview]

Hulliee schreef op zaterdag 16 januari 2021 @ 12:17:
[...]
Ik zou dat in een aparte .conf file zetten want de 01-pihole.conf wordt bij een update overschreven.

voor zover ik weet houd de installer / updater nu rekening met een aangepaste cache setting.

in /etc/pihole/setupVars.conf is er nu een setting CACHE_SIZE=

het is bovendien niet aan te raden settings te herhalen in een aparte config file. als 01-pihole.conf al een cache setting bevat, en er bestaat nog een config file waar de setting in herhaald wordt, zal pihole-FTL niet meer opstarten (foutmelding duplicate setting). Het is dus NIET zo dat, bij herhaling van een setting, met gewijzigde waarde, de laatste waarde zal gebruikt worden.

cache 0 kan niet gebruikt worden als DNSSEC enabled is in pihole-FTL, er moet cache zijn om bepaalde DNSSEC gerelateerde records in memory te bewaren.

zelf gebruik ik pihole-FTL cache setting 0, unbound + redis doet de caching en DNSSEC, werkt perfect.

[Raven]

DoeEensGek schreef op zaterdag 16 januari 2021 @ 11:38:
Vraagje, hebben jullie weleens last dat een website niet laad? Gewoon een gebruikelijke website zoals tweakers.net. Het duurt dan oneindig lang met uiteindelijk een foutmelding dat de website niet bestaat. Maar een simpele f5 en binnen no-time is de pagina beschikbaar.
Ik probeer uit te vogelen of dit aan pihole ligt. Heb het ook met mijn telefoon waarin apps gewoon of de browser oneindig aan het wachten is.

Je hebt niet toevallig IPv6 en een Android telefoon die ICMPv6 zit te blocken? Klinkt namelijk erg bekend als ik kijk naar mijn S7.

[Hulliee]

jpgview schreef op zaterdag 16 januari 2021 @ 12:42:
[...]


voor zover ik weet houd de installer / updater nu rekening met een aangepaste cache setting.

in /etc/pihole/setupVars.conf is er nu een setting CACHE_SIZE=

het is bovendien niet aan te raden settings te herhalen in een aparte config file. als 01-pihole.conf al een cache setting bevat, en er bestaat nog een config file waar de setting in herhaald wordt, zal pihole-FTL niet meer opstarten (foutmelding duplicate setting). Het is dus NIET zo dat, bij herhaling van een setting, met gewijzigde waarde, de laatste waarde zal gebruikt worden.

cache 0 kan niet gebruikt worden als DNSSEC enabled is in pihole-FTL, er moet cache zijn om bepaalde DNSSEC gerelateerde records in memory te bewaren.

zelf gebruik ik pihole-FTL cache setting 0, unbound + redis doet de caching en DNSSEC, werkt perfect.

Het ging mij er om dat in 01-pihole.conf-bestand bovenaan wordt aangegeven dat het bestand wordt overschreven.

Dat van die dubbele settings wist ik niet! Dan lijkt de setupVars.conf een betere manier.

[DoeEensGek]

Raven schreef op zaterdag 16 januari 2021 @ 12:47:
[...]

Je hebt niet toevallig IPv6 en een Android telefoon die ICMPv6 zit te blocken? Klinkt namelijk erg bekend als ik kijk naar mijn S7.

Het komt zowel op windows pc's voor als op android telefoons.

[DoeEensGek]

The Druid schreef op zaterdag 16 januari 2021 @ 12:07:
[...]


Unbound ook draaien, zo ja dan de configuration file /etc/dnsmasq.d/01-pihole.conf bewerken en de cache-size=1000 aanpassen naar 0. Tevens in de webinterface Use DNSSEC niet aan vinken.

@Hulliee @jpgview Ik draai geen unbound zover ik weet. DNSSEC is uitgevinkt dat was het al. CACHE_SIZE=10000, maar moet ik die nu wel of niet op 0 zetten? Zover ik uit @Hulliee zijn link begrijp moet ik die dus zo laten.

Of is unbound echt aanteraden? (Performance)

[ Voor 4% gewijzigd door DoeEensGek op 16-01-2021 16:06 ]

[Hulliee]

DoeEensGek schreef op zaterdag 16 januari 2021 @ 16:00:
[...]

@Hulliee @jpgview Ik draai geen unbound zover ik weet. DNSSEC is uitgevinkt dat was het al. CACHE_SIZE=10000, maar moet ik die nu wel of niet op 0 zetten? Zover ik uit @Hulliee zijn link begrijp moet ik die dus zo laten.

Of is unbound echt aanteraden? (Performance)

Ik heb idd unbound draaien en daarvoor heb ik dnssec uitstaan. Ik draai pi-hole en unbound in aparte docker-images. Qua performance weet ik niet zo je veel uit gaat halen.

Met Unbound draai je je dns-server. Je zit wat hoger in de dns-boom dus vooral voor privacy interessant

[Eärendil]

Hulliee schreef op zaterdag 16 januari 2021 @ 16:13:
[...]
Met Unbound draai je je dns-server. Je zit wat hoger in de dns-boom dus vooral voor privacy interessant

Het heeft voor je privacy niet alleen voordelen. Je deelt minder informatie met de DNS-server van je provider, Google of Cloudflare, maar doet in plaats daarvan wel een heleboel requests direct naar andere DNS-servers.

Ik heb de DNS-server van mijn provider ingevuld in Pi-Hole.

[nero355]

Eärendil schreef op zaterdag 16 januari 2021 @ 19:20:
Het heeft voor je privacy niet alleen voordelen. Je deelt minder informatie met de DNS-server van je provider, Google of Cloudflare, maar doet in plaats daarvan wel een heleboel requests direct naar andere DNS-servers.

Ik heb de DNS-server van mijn provider ingevuld in Pi-Hole.

Dan begrijp je niet wat een Unbound setup doet : https://docs.pi-hole.net/guides/unbound

Your recursive server will send a query to the DNS root servers: "Who is handling .net?"

Je communiceert dus direct met de wereldwijde Root DNS Servers die je ISP ook gebruikt!

[Webgnome]

Hulliee schreef op zaterdag 16 januari 2021 @ 12:17:
[...]


Ik zou dat in een aparte .conf file zetten want de 01-pihole.conf wordt bij een update overschreven.

Verder is het advies:
https://discourse.pi-hole...abled-or-disabled/27150/3

Pi-Hole cache enable
Pihole DNSSEC disable

Kun je in die directory een eigen conf zetten die dan autommamagisch wordt opgepakt? Want ik heb inderdaad nu bij elke upgrade dat ik mijn config moet restoren..

[Eärendil]

nero355 schreef op zaterdag 16 januari 2021 @ 20:16:
[...]

Dan begrijp je niet wat een Unbound setup doet : https://docs.pi-hole.net/guides/unbound

[...]

Je communiceert dus direct met de wereldwijde Root DNS Servers die je ISP ook gebruikt!

Uit die link:

After you set up your Pi-hole as described in this guide, this procedure changes notably:
[...]
5.Your recursive server will send a query to the DNS root servers: "Who is handling .net?"
6. The root server answers with a referral to the TLD servers for .net.
7. Your recursive server will send a query to one of the TLD DNS servers for .net: "Who is handling pi-hole.net?"
8. The TLD server answers with a referral to the authoritative name servers for pi-hole.net.
9. Your recursive server will send a query to the authoritative name servers: "What is the IP of pi-hole.net?"
10. The authoritative server will answer with the IP address of the domain pi-hole.net.[/li]
[...]

Dit klopt volgens mij niet helemaal. Er wordt volgens mij aan alle servers van de root-server tot de authoritive DNS-server direct gevraagd naar het domein dat je wilt hebben, maar het antwoord kan zijn "kijk verder bij de volgende server":

After you set up your Pi-hole as described in this guide, this procedure changes notably:
[...]
5.Your recursive server will send a query to the DNS root servers: "What is the IP address of pihole.net?"
6. The root server answers with: I don't know, but here is a referral to the TLD servers for .net.
7. Your recursive server will send a query to one of the TLD DNS servers for .net: "What is the IP address of pihole.net?"
8. The TLD server answers with I don't know, but here is a referral to the authoritative name servers for pi-hole.net.
9. Your recursive server will send a query to the authoritative name servers: "What is the IP of pi-hole.net?"
10. The authoritative server will answer with the IP address of the domain pi-hole.net.[/li]
[...]

Met Unbound laat je dus op meer plekken een spoor achter met een request van jouw IP-adres voor een bepaald domein.
Hoe dat uit het oogpunt van privacy afweegt tegen bijv. de DNS-server van je provider mag iedereen zelf afwegen, maar ik zie niet zo veel voordelen in zelf Unbound draaien.

[ Voor 3% gewijzigd door Eärendil op 16-01-2021 22:15 ]

[jpgview]

Eärendil schreef op zaterdag 16 januari 2021 @ 22:02:
Met Unbound laat je dus op meer plekken een spoor achter met een request van jouw IP-adres voor een bepaald domein.

1. root servers en TLD servers loggen bij mijn weten niet, logging zou de performantie van die servers geen goed doen, e.g. geen info die je achter laat. Maakt trouwens niet uit, want iedereen op de wereld maakt gebruik van root en TLD servers, kan moeilijk anders, Info zou dus alleen maar aangeven dat je bestaat, niet wat je doet.
2. Met unbound is het perfect mogelijk een locale copy van de root zone te gebruiken die je slechts eenmaal per week of zo update. Lees hier
3. De bedoeling van het gebruik van unbound is om er voor te zorgen dat niemand het volledige plaatje heeft van wat je doet. Ga je naar tweakers.net, dan weet alleen de DNS server van tweakers welke subdomains je opvraagd, Als je google (8.8.8.8) of clloudflare (1.1.1.1) gebruikt, hebben die providers info over alle domains die je bezoekt. Samengevat: Verdeel en heers

Webgnome schreef op zaterdag 16 januari 2021 @ 21:37:
[...]
Kun je in die directory een eigen conf zetten die dan autommamagisch wordt opgepakt? Want ik heb inderdaad nu bij elke upgrade dat ik mijn config moet restoren..

alle conf files die in /etc/dnsmasq.d worden door pihole-FTL gelezen en gebruikt. Je moet dus alleen maar oppassen dat je geen duplicate en / of foute settings hebt. Testen of alle conf files correct zijn kan je met het commando pihole-FTL dnsmasq-test (command line), als alles ok is, is het resultaat dnsmasq: syntax check OK.

[deHakkelaar]

Eärendil schreef op zaterdag 16 januari 2021 @ 22:02:
Met Unbound laat je dus op meer plekken een spoor achter met een request van jouw IP-adres voor een bepaald domein.
Hoe dat uit het oogpunt van privacy afweegt tegen bijv. de DNS-server van je provider mag iedereen zelf afwegen, maar ik zie niet zo veel voordelen in zelf Unbound draaien.

Niet het gehele domein.
De root servers die unbound gebruikt staan (meestal) in onderstaande bestandje:

pi@ph5:~ $ dpkg -S root.hints
dns-root-data: /usr/share/dns/root.hints

pi@ph5:~ $ cat /usr/share/dns/root.hints
;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC
;       under anonymous FTP as
;           file                /domain/named.cache
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
;
;       last update:     March 13, 2019
;       related version of root zone:     2019031302
;
; FORMERLY NS.INTERNIC.NET
;
.                        3600000      NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
;
; FORMERLY NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     199.9.14.201
B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:200::b
;
; FORMERLY C.PSI.NET
[..]

Stel unbound will het A record achterhalen voor gathering.tweakers.net.
Eerst vraagt unbound aan de root servers wie authoritive is voor het .net TLD domein:

pi@ph5:~ $ dig +noall +authority @A.ROOT-SERVERS.NET. soa net.
net.                    172800  IN      NS      e.gtld-servers.net.
net.                    172800  IN      NS      f.gtld-servers.net.
net.                    172800  IN      NS      m.gtld-servers.net.
net.                    172800  IN      NS      i.gtld-servers.net.
net.                    172800  IN      NS      j.gtld-servers.net.
net.                    172800  IN      NS      b.gtld-servers.net.
net.                    172800  IN      NS      a.gtld-servers.net.
net.                    172800  IN      NS      c.gtld-servers.net.
net.                    172800  IN      NS      k.gtld-servers.net.
net.                    172800  IN      NS      h.gtld-servers.net.
net.                    172800  IN      NS      l.gtld-servers.net.
net.                    172800  IN      NS      g.gtld-servers.net.
net.                    172800  IN      NS      d.gtld-servers.net.

Daarna aan bovenstaande wie authoritive is voor tweakers.net:

pi@ph5:~ $ dig +noall +authority @e.gtld-servers.net. soa tweakers.net.
tweakers.net.           172800  IN      NS      tweakdns.be.
tweakers.net.           172800  IN      NS      tweakdns.nl.
tweakers.net.           172800  IN      NS      tweakdns.eu.

En vervolgens vraagt unbound pas het volledige domein + A record aan bovenstaande servers:

pi@ph5:~ $ dig +noall +answer @tweakdns.nl. a gathering.tweakers.net.
gathering.tweakers.net. 60      IN      A       213.239.154.30

Het toverwoord is recursief.
Unbound gaat recursief de DNS boom langs totdat hij het juiste antwoord vindt.
En alleen de authoritive DNS server(s) voor een bepaald domein krijgt dus het volledig domein te zien waarnaar wordt gezocht.

[DoeEensGek]

Het lijkt erop dat ik het heb opgelost.


Dit waren mijn ingestelde DNS-servers.

En na een paar keer een DNS test Gedaan te hebben was dit bijna elke keer het resultaat. (Ziggo is 192.168.192.1 test is 82.196.9.45)


Er lijkt iets fout te gaan bij Ziggo en OpenNic DNS. Vooral die 1e snap ik niet, maar de 2e was snel duidelijk die bestond niet meer . Maar waarom slaat Pi-Hole deze dan niet standaard over? Vraagt Pi-Hole één voor één de servers af.

Goed is het Ziggo DNS (mijn modem is 192.168.192.1) even uitgevinkt en die andere door een nieuwe OpenNic vervangen en tadaa gelijk net zulke resultaten als de rest. IPv6 ook ingevuld voor de zekerheid, maar ik vraag me af of die wel gebruikt worden. Kan je ook hostnamen invullen bij de custom DNS-servers?

Het unbound verhaal laat ik nog even links liggen. Vind ik eigenlijk alleen interessant als daardoor sneller wordt maar tegen 20ms is dat de vraag.

[Mschamp]

DoeEensGek schreef op zondag 17 januari 2021 @ 12:40:
Het lijkt erop dat ik het heb opgelost.

[Afbeelding]
Dit waren mijn ingestelde DNS-servers.

En na een paar keer een DNS test Gedaan te hebben was dit bijna elke keer het resultaat. (Ziggo is 192.168.192.1 test is 82.196.9.45)
[Afbeelding]

Er lijkt iets fout te gaan bij Ziggo en OpenNic DNS. Vooral die 1e snap ik niet, maar de 2e was snel duidelijk die bestond niet meer . Maar waarom slaat Pi-Hole deze dan niet standaard over? Vraagt Pi-Hole één voor één de servers af.

Goed is het Ziggo DNS (mijn modem is 192.168.192.1) even uitgevinkt en die andere door een nieuwe OpenNic vervangen en tadaa gelijk net zulke resultaten als de rest. IPv6 ook ingevuld voor de zekerheid, maar ik vraag me af of die wel gebruikt worden. Kan je ook hostnamen invullen bij de custom DNS-servers?

Het unbound verhaal laat ik nog even links liggen. Vind ik eigenlijk alleen interessant als daardoor sneller wordt maar tegen 20ms is dat de vraag.

Geen idee of dat de reden is, maar ik heb de #53 er niet achter staan, enkel het IP adres. Als je toch de standaard poort gebruikt valt het te proberen. Zou normaal wel geen verschil mogen maken

[ Voor 3% gewijzigd door Mschamp op 17-01-2021 13:09 ]

[deHakkelaar]

DoeEensGek schreef op zondag 17 januari 2021 @ 12:40:
Maar waarom slaat Pi-Hole deze dan niet standaard over? Vraagt Pi-Hole één voor één de servers af.

https://docs.pi-hole.net/ftldns/dns-resolver/

Improve detection algorithm for determining the "best" forward destination

The DNS forward destination determination algorithm in FTLDNS's is modified to be much less restrictive than the original algorithm in dnsmasq.
We keep using the fastest responding server now for 1000 queries or 10 minutes (whatever happens earlier) instead of 50 queries or 10 seconds (default values in dnsmasq).
We keep the exceptions, i.e., we try all possible forward destinations if SERVFAIL or REFUSED is received or if a timeout occurs.
Overall, this change has proven to greatly reduce the number of actually performed queries in typical Pi-hole environments.
It may even be understood as being preferential in terms of privacy (as we send queries much less often to all servers).
This has been implemented in commit d1c163e.

[deHakkelaar]

Mschamp schreef op zondag 17 januari 2021 @ 13:01:
[...]
Geen idee of dat de reden is, maar ik heb de #53 er niet achter staan, enkel het IP adres. Als je toch de standaard poort gebruikt valt het te proberen. Zou normaal wel geen verschil mogen maken

Maakt niet uit.
#53 geeft alleen maar de poort aan die gebruikt moet worden.
EDIT: Net alsdat dig dat doet:

pi@ph5:~ $ dig +noall +stats @localhost -p 5335 a tweakers.net
;; Query time: 16 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sun Jan 17 13:45:07 CET 2021
;; MSG SIZE  rcvd: 57

[ Voor 22% gewijzigd door deHakkelaar op 17-01-2021 13:46 ]

[Kopernikus.1979]

Beste,

Ik heb een raar probleem betreffende de hostname op Pi-Hole van mijn "hoofd" desktop.

Een paar maand geleden is deze gecrasht en heb ik dus met Veeam backup een bare-metal backup teruggeplaatst (dus opstarten via USB stick en backup terugplaatsen). Tijdens het gebruik wordt de pc dus tijdelijk herkend als veeamre-xxxx.kopernikus-trusted.lan ipv zijn normale hostname desktop-1.kopernikus-trusted.lan Alles goed verkopen en ik blij we kunnen terug werken.

Nu enkele maanden later bekijk ik mijn Pi-Hole logs en wat blijkt is dat mijn pc in Pi-Hole nog steeds herkend wordt als veeamre-xxxx.kopernikus-trusted.lan ipv zijn normale hostname desktop-1.kopernikus-trusted.lan, dus wat doe ik cache leegmaken, reboot, zeker zijn dat er in de hosts file niets verkeerd staat, dns cache flush op mijn pc gedaan, hostname nagekeken (cmd --> hostname).

Echter blijft Pi-Hole die tijdelijk hostname gebruiken, ik heb geen idee waar hij deze vandaan haalt.
Ik kan natuurlijk een static hostname record maken daarmee is het opgelost maar ik wil graag de oorzaak weten...

Iemand een idee?

[jpgview]

Kopernikus.1979 schreef op zondag 17 januari 2021 @ 15:51:
Ik heb een raar probleem betreffende de hostname op Pi-Hole van mijn "hoofd" desktop.

pihole gebruikt in de web interface de namen uit de database (/etc/pihole/pihole-FTL.db)

Je kan de database bekijken / wijzigen met behulp van de tools, hier beschreven.

Hier vind je een script dat de tool voor jou instaleerd. Detail over het gebruik vind je in mijn manual, sectie 26/3

[Kopernikus.1979]

jpgview schreef op zondag 17 januari 2021 @ 16:00:
[...]


pihole gebruikt in de web interface de namen uit de database (/etc/pihole/pihole-FTL.db)

Je kan de database bekijken / wijzigen met behulp van de tools, hier beschreven.

Hier vind je een script dat de tool voor jou instaleerd. Detail over het gebruik vind je in mijn manual, sectie 26/3

Script geïnstalleerd, dan de database gewijzigd naar pihole-FTL.db en hostname gevonden.
Echter hoe wijzig ik deze nu? (link naar je manual werkt niet) en de FTL is blijkbaar read-only
Mag ik ook het paswoord wijzigen van admin naar iets anders? Of zal dit problemen geven met PiHole?
Dus als ik het goed begrijpt eenmaal PiHole een hostname aan zijn FTL database toevoegt kan je die enkel op deze manier wijzigen? Kan je dit dan ook gebruiken om devices een "naam" te geven waarvan je ze niet persé in je hosts bestand wil?

[Freee!!]

jpgview schreef op zondag 17 januari 2021 @ 16:00:
[...]
pihole gebruikt in de web interface de namen uit de database (/etc/pihole/pihole-FTL.db)

Je kan de database bekijken / wijzigen met behulp van de tools, hier beschreven.

Hier vind je een script dat de tool voor jou instaleerd. Detail over het gebruik vind je in mijn manual, sectie 26/3

Ziet er netjes uit, jammer, dat het niet direct werkt met Pi-Hole als Docker container.

[deHakkelaar]

jpgview schreef op zondag 17 januari 2021 @ 16:00:
[...]


pihole gebruikt in de web interface de namen uit de database (/etc/pihole/pihole-FTL.db)

Je kan de database bekijken / wijzigen met behulp van de tools, hier beschreven.

Hier vind je een script dat de tool voor jou instaleerd. Detail over het gebruik vind je in mijn manual, sectie 26/3

@jpgview , wanneer leer je eens te roeien met de riemen die je hebt

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db ".tables"
aliasclient        ftl                network            queries
counters           message            network_addresses

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db ".schema network_addresses"
CREATE TABLE IF NOT EXISTS "network_addresses" ( network_id INTEGER NOT NULL, ip TEXT UNIQUE NOT NULL, lastSeen INTEGER NOT NULL DEFAULT (cast(strftime('%s', 'now') as int)), name TEXT, nameUpdated INTEGER, FOREIGN KEY(network_id) REFERENCES network(id));

pi@ph5:~ $ sqlite3 --header /etc/pihole/pihole-FTL.db "SELECT * FROM network_addresses"
network_id|ip|lastSeen|name|nameUpdated
[..]
7|10.0.0.220|1608885600|laptop.dehakkelaar.nl|1608884040
[..]

pi@ph5:~ $ sudo sqlite3 /etc/pihole/pihole-FTL.db "UPDATE network_addresses SET name = REPLACE(name,'laptop.dehakkelaar.nl','potpal.dehakkelaar.nl') WHERE name LIKE '%laptop.dehakkelaar.nl%';"
pi@ph5:~ $

pi@ph5:~ $ sqlite3 --header /etc/pihole/pihole-FTL.db "SELECT * FROM network_addresses"
network_id|ip|lastSeen|name|nameUpdated
[..]
7|10.0.0.220|1608885600|potpal.dehakkelaar.nl|1608884040
[..]

Alles SQL gerelateerd valt te googlen/DuckDuck-en.
Ik wist de query ook niet maar vond hem meteen de eerste keer.

[ Voor 3% gewijzigd door deHakkelaar op 17-01-2021 16:45 ]

[jpgview]

Kopernikus.1979 schreef op zondag 17 januari 2021 @ 16:19:
[...]


Script geïnstalleerd, dan de database gewijzigd naar pihole-FTL.db en hostname gevonden.
Echter hoe wijzig ik deze nu? (link naar je manual werkt niet)
Mag ik ook het paswoord wijzigen van admin naar iets anders? Of zal dit problemen geven met PiHole?
Dus als ik het goed begrijpt eenmaal PiHole een hostname aan zijn FTL database toevoegt kan je die enkel op deze manier wijzigen? Kan je dit dan ook gebruiken om devices een "naam" te geven waarvan je ze niet persé in je hosts bestand wil?

Link naar manual werkt niet -> whitelist users.telenet.be

Mag ik ook het paswoord wijzigen van admin naar iets anders? nee, niet bij mijn weten, ook niet nodig, niet bereikbaar van buitenuit.

hostname detectie word door setting in /etc/pihole/pihole-FTL REFRESH_HOSTNAMES=, zie handleiding

experimenteren maar... in het slechtste geval:
- sudo service pihole-FTL stop
- sudo rm /etc/pihole/pihole-FTL.db
- sudo service pihole-FTL start

deHakkelaar schreef op zondag 17 januari 2021 @ 16:32:
[...]
@jpgview , wanneer leer je eens te roeien met de riemen die je hebt

Waarom? tweaker? alternatieven zijn interessant om te onderzoeken, je leert misschien ook nog iets.
- wijzigingen scripted aanbrengen -> SQLITE3, voorbeeld mmotti regexes
- bekijken of single item wijzigen -> web interface (phpliteadmin)

[ Voor 18% gewijzigd door jpgview op 17-01-2021 16:43 ]

[deHakkelaar]

@Kopernikus.1979 , maak eerst een backup voordat je in de dbase gaat wroeten:

code:

cd ~

pihole-FTL /etc/pihole/pihole-FTL.db ".backup main pihole-FTL.db.bak"

Restore met:

code:

sudo service pihole-FTL stop

sudo -u pihole pihole-FTL /etc/pihole/pihole-FTL.db ".restore main pihole-FTL.db.bak"

sudo service pihole-FTL start

[ Voor 9% gewijzigd door deHakkelaar op 19-09-2021 21:02 . Reden: pihole-FTL als vervanging van de sqlite3 binary ]

[Freee!!]

[quote]deHakkelaar schreef op zondag 17 januari 2021 @ 16:32:
[...]
@jpgview , wanneer leer je eens te roeien met de riemen die je hebt

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db ".tables"
aliasclient        ftl                network            queries
counters           message            network_addresses

"Error: database disk image is malformed"
Verouderd bestand, moet ergens anders zoeken.

[ Voor 6% gewijzigd door Freee!! op 17-01-2021 16:53 ]

[deHakkelaar]

jpgview schreef op zondag 17 januari 2021 @ 16:36:
Waarom? tweaker? alternatieven zijn interessant om te onderzoeken, je leert misschien ook nog iets.
- wijzigingen scripted aanbrengen -> SQLITE3, voorbeeld mmotti regexes
- bekijken of single item wijzigen -> web interface (phpliteadmin)

Je leert weinig als je alleen maar afhankelijk bent van muis klikbare dingetjes.
Als je geen web daemon hebt draaien, en je moet in een dbase wroeten, is het beter als je weet hoe dat moet en ook hoe de programatuur de dbase aanspreekt.

[Kopernikus.1979]

@jpgview
@deHakkelaar

Super, weer veel geleerd vandaag :-)

[deHakkelaar]

Freee!! schreef op zondag 17 januari 2021 @ 16:48:
"Error: database disk image is malformed"

Dat is geen goeie.
Je kunt de dbase proberen te repareren (googlen) maar denk dat dat niet makkelijk is.
Makkelijkst is om de dbase te deleten/moven en Pi-hole weer een nieuwe te laten aanmaken.

code:

sudo service pihole-FTL stop

sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL.db.malformed

sudo service pihole-FTL start

Je bent dan wel alles kwijt zoals queries in verleden etc.
Ook moet je je afvragen hoe het komt dat ie malformed is.

[ Voor 42% gewijzigd door deHakkelaar op 17-01-2021 16:57 ]

[jpgview]

Freee!! schreef op zondag 17 januari 2021 @ 16:48:
[quote]deHakkelaar schreef op zondag 17 januari 2021 @ 16:32:
[...]
@jpgview , wanneer leer je eens te roeien met de riemen die je hebt

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db ".tables"
aliasclient        ftl                network            queries
counters           message            network_addresses

"Error: database disk image is malformed"

begrijp niet waarom je mij over de error aanspreekt...

nog een voordeel van gebruik van phpliteadmin. Krijg op een eenvoudige manier inzicht over de structuur van de database:


het kan ook met SQLITE3 comando's, maar waarom moeilijk als het ook makelijk kan...

[deHakkelaar]

jpgview schreef op zondag 17 januari 2021 @ 16:58:
begrijp niet waarom je mij over de error aanspreekt...

Dat was foutje mijner zijde.
Heb al gecorrigeerd.

jpgview schreef op zondag 17 januari 2021 @ 16:58:
nog een voordeel van gebruik van phpliteadmin. Krijg op een eenvoudige manier inzicht over de structuur van de database:
[..]
het kan ook met SQLITE3 comando's, maar waarom moeilijk als het ook makelijk kan...

Ik heb precies hetzelfde als ik onderstaande doe:

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db ".schema network_addresses"
CREATE TABLE IF NOT EXISTS "network_addresses" ( network_id INTEGER NOT NULL, ip TEXT UNIQUE NOT NULL, lastSeen INTEGER NOT NULL DEFAULT (cast(strftime('%s', 'now') as int)), name TEXT, nameUpdated INTEGER, FOREIGN KEY(network_id) REFERENCES network(id));

[Freee!!]

deHakkelaar schreef op zondag 17 januari 2021 @ 16:56:
[...]
Dat is geen goeie.
Je kunt de dbase proberen te repareren (googlen) maar denk dat dat niet makkelijk is.
Makkelijkst is om de dbase te deleten/moven en Pi-hole weer een nieuwe te laten aanmaken.

code:

sudo service pihole-FTL stop

sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL.db.malformed

sudo service pihole-FTL start

Je bent dan wel alles kwijt zoals queries in verleden etc.
Ook moet je je afvragen hoe het komt dat ie malformed is.

Het gevonden bestand is zwaar verouderd en ik zit met de kleine complicatie, dat ik met Docker werk, dus standaard locaties werken al niet.

EDIT:
Het lijkt erop, dat de FTL database in de Docker image standaard uitgeschakeld is/niet opgeslagen wordt.

[ Voor 7% gewijzigd door Freee!! op 17-01-2021 17:29 ]

[Kopernikus.1979]

Nu snap ik het helemaal niet meer...

Ik heb dus de hostname via de tool aangepast alsook de database volledig gewist (om zeker te zijn)
En toch... daar is hij weer onder de naam veeamre-xxx ipv desktop-1
Waar blijft hij dit uithalen???

[ Voor 4% gewijzigd door Kopernikus.1979 op 17-01-2021 17:30 ]

[deHakkelaar]

Kopernikus.1979 schreef op zondag 17 januari 2021 @ 17:27:
Nu snap ik het helemaal niet meer...

Ik heb dus de hostname via de tool aangepast alsook de database volledig gewist (om zeker te zijn)
En toch... daar is hij weer onder de naam veeamre-xxx ipv desktop-1
Waar blijft hij dit uithalen???

Als je bent gestart met een nieuwe dbase, dan via de DHCP uitwisseling.
De clients adverteren dan hun hostnaam aan de box die DHCP doet:

dehakkelaar@laptop:~$ cat /etc/dhcp/dhclient.conf
[..]
send host-name = gethostname();

[ Voor 3% gewijzigd door deHakkelaar op 17-01-2021 17:36 ]

[Kopernikus.1979]

deHakkelaar schreef op zondag 17 januari 2021 @ 17:34:
[...]


Als je bent gestart met een nieuwe dbase, dan via de DHCP uitwisseling.
De clients adverteren dan hun hostnaam aan de box die DHCP doet:

dehakkelaar@laptop:~$ cat /etc/dhcp/dhclient.conf
[..]
send host-name = gethostname();

En hoe los ik dit probleem dan op?
Als DHCP server gebruik ik mijn USG, en de hostname van de pc staat correct ingesteld.
Tenzij mijn pc de hostname ergens hardcoded heeft en de default override..

[ Voor 7% gewijzigd door Kopernikus.1979 op 17-01-2021 17:40 ]

[deHakkelaar]

Kopernikus.1979 schreef op zondag 17 januari 2021 @ 17:38:
En hoe los ik dit probleem dan op?
Als DHCP server gebruik ik mijn USG, en de hostname van de pc staat correct ingesteld.
Tenzij mijn pc de hostname ergens hardcoded heeft en de default override..

code:

nslookup <IP_VAN_PC> <IP_VAN_USG>

???

[Kopernikus.1979]

deHakkelaar schreef op zondag 17 januari 2021 @ 17:41:
[...]

code:

nslookup <IP_VAN_PC> <IP_VAN_USG>

???

code:

Microsoft Windows [Version 10.0.19042.746]
(c) 2020 Microsoft Corporation. Alle rechten voorbehouden.

C:\Windows\system32>nslookup 10.10.10.10 10.10.1.1
Server:  gateway.Kopernikus-Native.lan
Address:  10.10.1.1

Name:    veeamre-t4qgyuh.Kopernikus-Trusted.lan
Address:  10.10.10.10


C:\Windows\system32>hostname
DESKTOP-1

C:\Windows\system32>

Dus wss is het de USG dat zijn DHCP tabel moet "refreshen"?

[ Voor 5% gewijzigd door Kopernikus.1979 op 17-01-2021 17:44 ]

[deHakkelaar]

Kopernikus.1979 schreef op zondag 17 januari 2021 @ 17:42:
[...]

code:

Microsoft Windows [Version 10.0.19042.746]
(c) 2020 Microsoft Corporation. Alle rechten voorbehouden.

C:\Windows\system32>nslookup 10.10.10.10 10.10.1.1
Server:  gateway.Kopernikus-Native.lan
Address:  10.10.1.1

Name:    veeamre-t4qgyuh.Kopernikus-Trusted.lan
Address:  10.10.10.10


C:\Windows\system32>hostname
DESKTOP-1

C:\Windows\system32>

Dus wss is het de USG dat zijn DHCP tabel moet "refreshen"?

Je USG heeft van de PC de hostnaam veeamre... door gekregen via DHCP.
Andere namen van clients zijn wel correct ?
Anders vermoed ik idd dat of de USG doet wat met de hostnamen (eigen records bv) of de PC geeft de verkeerde hostnaam door aan je USG.

[deHakkelaar]

@Kopernikus.1979 , als je tcpdump beschikbaar hebt op de USG kun je misschien de hostnaam sniffen zodra je op de PC je IP vernieuwt.
Wel juiste interface van de USG hieronder meegeven ... kan mischien ook -i eth0 argument weg laten.

code:

sudo tcpdump -lntXq -i eth0 udp port 67

[ Voor 21% gewijzigd door deHakkelaar op 17-01-2021 17:53 ]

[Kopernikus.1979]

deHakkelaar schreef op zondag 17 januari 2021 @ 17:46:
[...]

Je USG heeft van de PC de hostnaam veeamre... door gekregen via DHCP.
Andere namen van clients zijn wel correct ?
Anders vermoed ik idd dat of de USG doet wat met de hostnamen (eigen records bv) of de PC geeft de verkeerde hostnaam door aan je USG.

Probleem gevonden...
Alle DHCP requests worden in de USG opgeslagen in /etc/hosts
Stond vol dubbel, oud enz, simpelweg file even gewist en probleem opgelost

[nero355]

@Kopernikus.1979

Gokje :

De VEEAM Restore heb je gedaan met een Live CD achtige USB Stick die ervoor kan zorgen dat :
- Er iets unieks tijdens het restoren aan de teruggeplaatste data kan worden toegevoegd, zoals een unieke Hostname.
- De omgeving die wordt opgestart vanaf de USB Stick heeft de laatste DHCP Request gedaan met een Hostname die de Live CD achtige omgeving gebruikt.

Dus als je dat in de toekomst kan voorkomen dan zal je dit gezeik nooit meer tegenkomen

[deHakkelaar]

@nero355 , wel even wakker blijven ... nog ff

Kopernikus.1979 schreef op zondag 17 januari 2021 @ 18:05:
Probleem gevonden...
Alle DHCP requests worden in de USG opgeslagen in /etc/hosts
Stond vol dubbel, oud enz, simpelweg file even gewist en probleem opgelost

Als goed is doet Pi-hole elk uur een reverse lookup voor client IP's welke bekend zijn om de namen in de dbase te verversen.

EDIT: vergat te melden dat ik het een heel rare implementatie vind van die USG dat deze DHCP ontdekte hostnamen in de /etc/hosts file opslaat.
Heel erg spartaans

[ Voor 16% gewijzigd door deHakkelaar op 17-01-2021 18:40 ]

[nero355]

@deHakkelaar

Voorkomen is beter dan genezen net als de oorzaak weten dus daarom nog effe mijn reply erbij gedaan

[Kopernikus.1979]

deHakkelaar schreef op zondag 17 januari 2021 @ 18:28:
@nero355 , wel even wakker blijven ... nog ff


[...]

Als goed is doet Pi-hole elk uur een reverse lookup voor client IP's welke bekend zijn om de namen in de dbase te verversen.

EDIT: vergat te melden dat ik het een heel rare implementatie vind van die USG dat deze DHCP ontdekte hostnamen in de /etc/hosts file opslaat.
Heel erg spartaans

Ja, is inderdaad raar, en vooral dat het niet "gerefreshed" wordt, mss wel bij een reboot...
Op die manier worden ze opgeslaan:

code:

10.10.10.162     DESKTOP-1.Kopernikus-Trusted.lan        #on-dhcp-event 2c:f0:5d

[ Voor 10% gewijzigd door Kopernikus.1979 op 17-01-2021 20:09 ]

[ed1703]

Kopernikus.1979 schreef op zondag 17 januari 2021 @ 20:06:
[...]


Ja, is inderdaad raar, en vooral dat het niet "gerefreshed" wordt, mss wel bij een reboot...
Op die manier worden ze opgeslaan:

code:

10.10.10.162     DESKTOP-1.Kopernikus-Trusted.lan        #on-dhcp-event 2c:f0:5d

Op de USG wordt /etc/hosts gevuld door het vyatta Perl script die bij elke dhcpaanvraag kijkt of de dhcpclient de hostname meegeeft. Zo ja, dan zal deze worden toegevoegd. Het script wordt aangeroepen via de dhcp-server daemon. Op de USG draait ook dnsmasq en deze maakt hier gebruik van om je USG dns mee te vullen (no-hosts staat niet in de dnsmasq config). Helaas gaat het opschonen van die file niet zo goed en elke keer als je met een nieuwe naam komt voegt vyatta deze gewoon toe. DNSmasq boeit het niet als het meerdere keren voor komt, behalve bij PTR dan. Dat script is niet zo geweldig geschreven zullen we maar zeggen. De file schoont niet op bij een reboot, vziw.

[Kopernikus.1979]

ed1703 schreef op zondag 17 januari 2021 @ 20:51:
[...]

Op de USG wordt /etc/hosts gevuld door het vyatta Perl script die bij elke dhcpaanvraag kijkt of de dhcpclient de hostname meegeeft. Zo ja, dan zal deze worden toegevoegd. Het script wordt aangeroepen via de dhcp-server daemon. Op de USG draait ook dnsmasq en deze maakt hier gebruik van om je USG dns mee te vullen (no-hosts staat niet in de dnsmasq config). Helaas gaat het opschonen van die file niet zo goed en elke keer als je met een nieuwe naam komt voegt vyatta deze gewoon toe. DNSmasq boeit het niet als het meerdere keren voor komt, behalve bij PTR dan. Dat script is niet zo geweldig geschreven zullen we maar zeggen. De file schoont niet op bij een reboot, vziw.

Zou het dan geen idee zijn een script op de USG te zetten die de hosts file nu en dan wist? Gezien ik Pi-Hole als DNS gebruik en niet mijn USG is het enige functie het doorgeven van de hostnames. Of zie ik dit verkeerd?

Zou de "nieuwe" Dreammachine Pro hetzelfde probleem hebben? Gezien deze niet langer gebasseerd is op vyatta (edge os). Alhoewel ik momenteel weinig reden zie om over te stappen zeker al niet door het ontbreken van support voor de config.gateway.json, ik weet er zijn al alternatieven via docker enz

[ed1703]

Kopernikus.1979 schreef op zondag 17 januari 2021 @ 21:06:
[...]


Zou het dan geen idee zijn een script op de USG te zetten die de hosts file nu en dan wist?

Je kunt in /config/scripts/post-config.d/ op je usg custom scripts maken. Ze moeten dacht ik wel op .sh eindigen en uiteraard executable maken. Daar zou je dat in kunnen doen. Na het verwijderen wel een restart van dnsmasq in het script zetten.

De scripts overleven een reboot en firmware upgrade.
Voor tasks is er task scheduler via config.gateway.json
Zit niet zo diep in de mogelijkheden daarvan.

[ Voor 13% gewijzigd door ed1703 op 17-01-2021 21:22 ]

[webside007]

Laatste docker image werkt niet meer op mijn Synology...
Wat ik heb gedaan:
- laatste pihole image gedownload
- pihole docker gestopt
- image "gewist"
- pihole terug gestart -> deze crashed nu continue en herstart steeds automatisch
- ik heb de docker app zelfs verwijderd dan en opnieuw aangemaakt -> blijft crashen
Is laatste docker image kapot/slecht?
Iemand die het ook heeft voorgehad?

[Webgnome]

@webside007 'Het is stuk, help'.

Ik denk dat het fijn zou zijn als we op zijn minst logs kunnen zien van het e.e.a. om te bepalen wat er kapot is.

[Kopernikus.1979]

ed1703 schreef op zondag 17 januari 2021 @ 21:17:
[...]

Je kunt in /config/scripts/post-config.d/ op je usg custom scripts maken. Ze moeten dacht ik wel op .sh eindigen en uiteraard executable maken. Daar zou je dat in kunnen doen. Na het verwijderen wel een restart van dnsmasq in het script zetten.

De scripts overleven een reboot en firmware upgrade.
Voor tasks is er task scheduler via config.gateway.json
Zit niet zo diep in de mogelijkheden daarvan.

Werkt prima :-)

Terwijl we bezig zijn, de volgende optie in PiHole, enabled/disable? Graag jullie mening

Never forward reverse lookups for private IP ranges

[webside007]

Webgnome schreef op maandag 18 januari 2021 @ 14:28:
@webside007 'Het is stuk, help'.

Ik denk dat het fijn zou zijn als we op zijn minst logs kunnen zien van het e.e.a. om te bepalen wat er kapot is.

Daar kan ik nu niet aan, ik reageer later wel.
Vroeger ging mijn beschreven methode steeds perfect voor een upgrade, en nu niet meer.

[DoeEensGek]

Toch maar unbound geïnstalleerd en draaiend nu. Cache-size op 0 gezet. Gisteravond kreeg ik toch weer last van websites die niet laadde en leek alles af en toe weer trager te gaan. Unbound geeft in eerste instantie gelijk weer een 'fris gevoel'. Pagina's laden weer zeer snel, maar tijd zal het leren.

[deHakkelaar]

Kopernikus.1979 schreef op maandag 18 januari 2021 @ 14:30:
[...]
Terwijl we bezig zijn, de volgende optie in PiHole, enabled/disable? Graag jullie mening

Never forward reverse lookups for private IP ranges

Hangt er vanaf.
Als Pi-hole DHCP doet, heb je geen forwarded reverse lookups nodig dus kan je deze setting activeren zodat niks lekt upstream.
Als je afhankelijk bent van een upstream DNS server die records heeft van je LAN, deactiveer je de setting.
Upstream DNS server kan zijn bv je router die DHCP doet, en je dan geen CF hoeft te gebruiken in Pi-hole.
Nadeel van bovenstaande en waarom CF efficienter is, DNS verzoekjes gaan eerst door twee resolvers voordat het naar internet gaat.
Of bv een Windhoos DC upstream waar je reverse lookups voor je LAN naar toe wilt kunnen schieten.

[deHakkelaar]

@nero355 , ter rectificatie nadat ik @ed1703 z'n uitleg heb gelezen,
je had gelijk:

nero355 schreef op zondag 17 januari 2021 @ 18:09:
@Kopernikus.1979

Gokje :

De VEEAM Restore heb je gedaan met een Live CD achtige USB Stick die ervoor kan zorgen dat :
- Er iets unieks tijdens het restoren aan de teruggeplaatste data kan worden toegevoegd, zoals een unieke Hostname.
- De omgeving die wordt opgestart vanaf de USB Stick heeft de laatste DHCP Request gedaan met een Hostname die de Live CD achtige omgeving gebruikt.

Dus als je dat in de toekomst kan voorkomen dan zal je dit gezeik nooit meer tegenkomen

FUBAR

[Pompi]

Ik was al een tijdje vergeten om mijn Pi-Hole te updaten, omdat het gewoon prima werkte maar zag recent dit topic langskomen en bedacht toen dat ik hem maar eens moest gaan updaten.
Kwam er achter dat ik eerst mijn Raspberry Pi moest updaten naar Stretch, dat dus eerst gedaan zonder problemen. Toen Pi-Hole geprobeerd te updaten en leek goed te gaan tot het einde, kreeg toen de volgende error.

code:

No IP addresses found! Please run 'pihole -r' to reconfigure
Unable to complete update, please contact Pi-hole Support

Daarna kon ik de Pi-Hole ook niet meer bereiken via mijn 192.168.x.y/admin, dus toen maar de voorgestelde pihole -r gedaan en voor repair gekozen.
Toen kreeg ik aan het einde deze error.

code:

Retrieval of supported OS list failed. dig failed with return code 10. 
Unable to determine if the detected OS (Raspbian 9) is supported

En daarna de voorgestelde PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r gedaan. En toen kreeg ik uiteindelijk deze error.

code:

[✗] Downloading and Installing FTL
Error: URL https://github.com/pi-hole/ftl/releases/latest/download/pihole-FTL-armv7-linux-gnueabihf not found
[✗] FTL Engine not installed

En nu weet ik niet goed wat ik moet doen, want kan de webpagina van de Pi-Hole nog steeds niet bereiken. Dus ik hoop dat een van jullie toevallig weten wat ik moet doen. Had gelukkig wel voordat ik de update probeerde via teleporter een back-up gemaakt.

[To_Tall]

Stretch is ook al niet meer supported. 2 jaar dacht ik?? Debian Buster is current branche.

[Lizard]

@Pompi Ik zou de online installer gewoon nog een keer uitvoeren:

code:

curl -sSL https://install.pi-hole.net | bash

Die herkent ook dat er een bestaande install is.

[Pompi]

To_Tall schreef op maandag 18 januari 2021 @ 23:12:
Stretch is ook al niet meer supported. 2 jaar dacht ik?? Debian Buster is current branche.

Volgens hun website zijn zowel Stretch als Buster Supported Operating Systems. Ik had juist niet direct naar Buster door geupdate omdat ik problemen wou voorkomen door niet in 1x heel veel wijzigingen te doen, maar helaas.

Lizard schreef op maandag 18 januari 2021 @ 23:18:
@Pompi Ik zou de online installer gewoon nog een keer uitvoeren:

code:

curl -sSL https://install.pi-hole.net | bash

Die herkent ook dat er een bestaande install is.

Wat doet dit dan? Als het herkend dat er een bestaande install is.

---

Apart genoeg is nu ik vanochtend wakker werd de Pi-Hole weer bereikbaar via het adres, alleen werkt hij nog steeds niet. Heb zelfs 8.8.8.8 moeten toevoegen als DNS want anders werkte internet niet.
Zou dit kunnen komen doordat dit leeg is? Want voor de update stond daar wel o.a. eth0

En zou ik dit dan kunnen oplossen door pihole reconfigure te runnen? Voordat ik zonder te weten meer stuk zou maken.

[Pompi]

Hmm het lijkt er op alsof er met de update van de Pi iets mis is gegaan, want ik kan nu ook niet meer sudo apt update doen. Dan krijg ik een error dat hij geen connectie kan maken met servers.

code:

Fout:1 http://archive.raspberrypi.org/debian buster InRelease                  
  Tijdelijke fout bij het opzoeken van 'archive.raspberrypi.org'
Fout:2 http://raspbian.raspberrypi.org/raspbian buster InRelease               
  Tijdelijke fout bij het opzoeken van 'raspbian.raspberrypi.org'

Na rondje googlen lijkt het te komen doordat DNS niet werkt want met pingen krijg ik het volgende

code:

ping -c 1 google.com
ping: google.com: Tijdelijk probleem in naamsherleiding

en dit werkt weer wel

code:

ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=8.50 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 8.501/8.501/8.501/0.000 ms

Daarna gekeken naar resolv.conf, omdat bij andere die een vergelijkbaar probleem hadden dit gevraagd werd en daar kreeg ik

code:

cat /etc/resolv.conf
# Generated by resolvconf
nameserver ipmodem

Dus dat lijkt voor zover ik met mijn beperkte kennis kan zeggen correct. Alleen weet ik nu niet echt wat ik kan doen om te zorgen dat het wel weer gaat werken. Ook omdat ik mijn modem gewoon kan pingen via ipadres wat stond bij nameserver
Alle suggesties zijn dus meer dan welkom .

[Freee!!]

DNS even niet door de Pi-Hole laten doen totdat de zaak opgelost is.

[Pompi]

Freee!! schreef op dinsdag 19 januari 2021 @ 11:35:
DNS even niet door de Pi-Hole laten doen totdat de zaak opgelost is.

Volgens mij heb ik dat al gedaan, heb in modem bij DNS server al het statische IP van de Pi weg gehaald en daarna de DNS server van Ziggo toegevoegd nadat het leeg laten ook niks deed. Dat had ik gedaan voor mijn laatste post, dus volgens mij had het dan moeten werken maar blijkbaar toch niet.

[Freee!!]

Pompi schreef op dinsdag 19 januari 2021 @ 11:48:
[...]
Volgens mij heb ik dat al gedaan, heb in modem bij DNS server al het statische IP van de Pi weg gehaald en daarna de DNS server van Ziggo toegevoegd nadat het leeg laten ook niks deed. Dat had ik gedaan voor mijn laatste post, dus volgens mij had het dan moeten werken maar blijkbaar toch niet.

De DNS gegevens ook ververst op de machine, waarop je Pi-Hole moet draaien?

[Pompi]

Freee!! schreef op dinsdag 19 januari 2021 @ 11:54:
[...]

De DNS gegevens ook ververst op de machine, waarop je Pi-Hole moet draaien?

Hoe doe ik dat op een Raspberry Pi? Want de DHCPCD geeft bij static domain_name_servers mijn modem IP weer. Dat deed mij denken dat die het ook al correct had. Is bijvoorbeeld een reboot genoeg?

Of moet ik bij static domain_name_servers de Ziggo DNS server zetten in plaats dat ik verwijs naar mijn modem? Waar dit dan al staat?

[Freee!!]

Pompi schreef op dinsdag 19 januari 2021 @ 12:38:
[...]

Hoe doe ik dat op een Raspberry Pi?

sudo systemd-resolve --flush-caches

Want de DHCPCD geeft bij static domain_name_servers mijn modem IP weer. Dat deed mij denken dat die het ook al correct had.

Dat zou al goed moeten zijn dan, als je modem de juiste DNS instellingen heeft.

Is bijvoorbeeld een reboot genoeg?

Dat is meer dan genoeg.

Of moet ik bij static domain_name_servers de Ziggo DNS server zetten in plaats dat ik verwijs naar mijn modem? Waar dit dan al staat?

Geen static domain_name_system servers opgeven. Zorg, dat je DHCP-server die doorgeeft.

[jpgview]

Pi-hole FTL v5.5 released - UPDATE TODAY

an important security update, read here

edit
update causes errors in pihole-FTL log, read here

Ik veronderstel dat er snel een nieuwe update zal komen.
/edit

edit2
error can be ignored, lees hier
/edit2

edit3
just received github notification for pihole-FTL 5.5.1
/edit3

[ Voor 67% gewijzigd door jpgview op 19-01-2021 16:20 ]

[Webgnome]

ze zijn wel lekker bezig de laatste tijd met updates. Nou ja vanavond maar weer de update aanslingeren dan

[Freee!!]

Webgnome schreef op dinsdag 19 januari 2021 @ 13:55:
ze zijn wel lekker bezig de laatste tijd met updates. Nou ja vanavond maar weer de update aanslingeren dan

Ik verwacht binnen een paar uur een mailtje, dat de update automatisch geïnstalleerd is.

EDIT:
Eerste mailtje is al binnen.

[ Voor 5% gewijzigd door Freee!! op 19-01-2021 14:18 ]

[iLLuSion_xGen]

Hoi,

Ik kom er niet uit dus daarom dat ik het hier vraag.
Ik heb sinds kort via VirtualBox Ubuntu 20.04 LTS geïnstalleerd, netjes als bridged ingesteld zoals het hoort.
Maar als ik firefox open krijgt deze gewoon ads door terwijl mijn Pihole op men host wel degelijk werkt. In de instellingen van de VM staat de DNS op automatisch (en geeft ook hiermee het correcte DNS adres van de Pihole weer) en ik heb deze ook al veranderd en manueel ingevuld maar zonder oplossing. Ook de DNS van Adguard schijnt niet te werken.
De Pihole staat overigens op een RP3b+ en dient als DHCP-server.

Is er iets wat ik over het hoofd zie?

[ Voor 5% gewijzigd door iLLuSion_xGen op 19-01-2021 14:40 ]

[Freee!!]

iLLuSion_xGen schreef op dinsdag 19 januari 2021 @ 14:39:
Hoi,

Ik kom er niet uit dus daarom dat ik het hier vraag.
Ik heb sinds kort via VirtualBox Ubuntu 20.04 LTS geïnstalleerd, netjes als bridged ingesteld zoals het hoort.
Maar als ik firefox open krijgt deze gewoon ads door terwijl mijn Pihole op men host wel degelijk werkt. In de instellingen van de VM staat de DNS op automatisch (en geeft ook hiermee het correcte DNS adres van de Pihole weer) en ik heb deze ook al veranderd en manueel ingevuld maar zonder oplossing. Ook de DNS van Adguard schijnt niet te werken. Is er iets wat ik over het hoofd zie?

Kijk eens in de config van Firefox of die niet toevallig DoH gebruikt, dat gaat volledig langs je Pi-Hole.

[iLLuSion_xGen]

Freee!! schreef op dinsdag 19 januari 2021 @ 14:40:
[...]

Kijk eens in de config van Firefox of die niet toevallig DoH gebruikt, dat gaat volledig langs je Pi-Hole.

Geen DoH, Proxyinstellingen van systeem gebruiken is aangevinkt

[Pompi]

Freee!! schreef op dinsdag 19 januari 2021 @ 12:54:
[...]

sudo systemd-resolve --flush-caches

[...]

Dat zou al goed moeten zijn dan, als je modem de juiste DNS instellingen heeft.

[...]

Dat is meer dan genoeg.

[...]

Geen static domain_name_system servers opgeven. Zorg, dat je DHCP-server die doorgeeft.

Heeft helaas niet geholpen, de Pi is ook echt de enigste in mijn netwerk die dit probleem heeft. Bij google pingen geeft hij nog steeds aan dat tijdelijk de naam niet kan worden herleid, de update functie kan ook nog geen verbinding maken.
Ik kom wel steeds dichterbij het punt dat ik de SD kaart er uit ga halen en er gewoon een verse image op zet, al wil ik dat liever voorkomen omdat verder alles goed ingesteld is/was.

[Freee!!]

Pompi schreef op dinsdag 19 januari 2021 @ 14:53:
[...]
Heeft helaas niet geholpen, de Pi is ook echt de enigste in mijn netwerk die dit probleem heeft. Bij google pingen geeft hij nog steeds aan dat tijdelijk de naam niet kan worden herleid, de update functie kan ook nog geen verbinding maken.
Ik kom wel steeds dichterbij het punt dat ik de SD kaart er uit ga halen en er gewoon een verse image op zet, al wil ik dat liever voorkomen omdat verder alles goed ingesteld is/was.

Dan heeft die Pi dus ergens verkeerde DNS-instellingen. Misschien een idee om die tijdelijk op 8.8.8.8 te zetten

[jpgview]

Pompi schreef op dinsdag 19 januari 2021 @ 14:53:
[...]

Heeft helaas niet geholpen, de Pi is ook echt de enigste in mijn netwerk die dit probleem heeft. Bij google pingen geeft hij nog steeds aan dat tijdelijk de naam niet kan worden herleid, de update functie kan ook nog geen verbinding maken.
Ik kom wel steeds dichterbij het punt dat ik de SD kaart er uit ga halen en er gewoon een verse image op zet, al wil ik dat liever voorkomen omdat verder alles goed ingesteld is/was.

De meer recente versies van pihole blokken NIET op de host zelf (als dat het probleem is)

Ik vond het persoonlijk vervelend dat op de host (in mijn geval een pi) het resultaat anders was (altijd resolved, geen blocking) en heb daarom aan /etc/dhcpcd.conf de setting static domain_name_servers=127.0.0.1 ::1 toegevoegd, waarna het resultaat op alle machines in de default groep hetzelfde is.

Misschien is dat je probleem?

Let wel, ik had een blocklist, die ervoor zorgde dat sudo apt-get -Y upgrade niet meer werkte, en moest een domain whitelisten om het terug aan de praat te krijgen.

[klungeltweaker]

Met hoofdletters:

https://pi-hole.net/2021/...-5-released-update-today/

[Pompi]

Freee!! schreef op dinsdag 19 januari 2021 @ 14:57:
[...]

Dan heeft die Pi dus ergens verkeerde DNS-instellingen. Misschien een idee om die tijdelijk op 8.8.8.8 te zetten

Moet ik die dan alleen in resolv.conf aanpassen of ook in dhcpcd.conf?

jpgview schreef op dinsdag 19 januari 2021 @ 15:07:
[...]


De meer recente versies van pihole blokken NIET op de host zelf (als dat het probleem is)

Ik vond het persoonlijk vervelend dat op de host (in mijn geval een pi) het resultaat anders was (altijd resolved, geen blocking) en heb daarom aan /etc/dhcpcd.conf de setting static domain_name_servers=127.0.0.1 ::1 toegevoegd, waarna het resultaat op alle machines in de default groep hetzelfde is.

Misschien is dat je probleem?

Let wel, ik had een blocklist, die ervoor zorgde dat sudo apt-get -Y upgrade niet meer werkte, en moest een domain whitelisten om het terug aan de praat te krijgen.

Ik heb tijdelijk via de webinterface Pihole zelf indefinitely disabled, zodat ik eerst weer alles werkend kon krijgen dus mag hopen dat het niet komt door een blocklist.

---

Alvast heel erg bedankt richting iedereen die meedenkt, is erg fijn om de hulp te krijgen van meer ervaren personen.

[ Voor 51% gewijzigd door Pompi op 19-01-2021 15:11 ]

[jpgview]

klungeltweaker schreef op dinsdag 19 januari 2021 @ 15:07:
Met hoofdletters:

https://pi-hole.net/2021/...-5-released-update-today/

lees hier en hier, er is een probleempje, ff wachten???

edit
error can be ignored, lees hier
/edit

edit2
just received github notification for pihole-FTL 5.5.1
/edit2

[ Voor 27% gewijzigd door jpgview op 19-01-2021 16:21 ]

[klungeltweaker]

Update op mijn reserve pi B+ (dietpi) is goed gegaan:

[2021-01-19 14:20:46.151 2568M] Reloading DNS cache
[2021-01-19 14:20:46.153 2568M] Blocking status is enabled
[2021-01-19 14:20:46.253 2568/T2572] SQLite3 message: file unlinked while open: /etc/pihole/gravity.db (28)
[2021-01-19 14:20:46.539 2568/T2572] Compiled 2 whitelist and 21 blacklist regex filters for 7 clients in 184.3 msec
[2021-01-19 14:25:11.044 2568M] Resizing "FTL-dns-cache" from 4096 to (512 * 16) == 8192 (/dev/shm: 1.2MB used, 251.4MB total)
[2021-01-19 14:26:58.420 2568M] Reloading DNS cache
[2021-01-19 14:26:58.422 2568M] Blocking status is enabled
[2021-01-19 14:26:58.566 2568/T2572] SQLite3 message: file unlinked while open: /etc/pihole/gravity.db (28)
[2021-01-19 14:26:58.946 2568/T2572] Compiled 2 whitelist and 21 blacklist regex filters for 7 clients in 162.0 msec
[2021-01-19 14:36:38.293 2568M] Resizing "FTL-strings" from 28672 to (32768 * 1) == 32768 (/dev/shm: 1.2MB used, 251.4MB total)

Komt uit pihole-FTL.log
Queries lopen ook prima.
Upstream is Unbound die op dezelfde pi loopt.