[Pi-Hole] Ervaringen & discussie

[Freee!!]

Webgnome schreef op zondag 18 oktober 2020 @ 11:29:
@Freee!! Heb je de DHCP server op een van de twee pi's draaien of staat die op een compleet ander systeem?

Die staat erbij op de RPi4B, die staat toch maar het grootste deel van de tijd te niksen met maar elf containers (Pi-Hole, 2* Unbound, Watchtower, Portainer, Yacht, 2* DuckDNS, SMTP, Heimdall en een Omada Controller).

[Webgnome]

Ik weet nog niet wat ik ga doen. Aan de ene kant lijkt het overkill om alles op eigen pi's te zetten. Aan de andere kant wat maakt het uit? De kosten zijn te negeren zeker als je her raspberry pi zero's voor gebruikt. (helaas is daar geen ethernet hat meer voor te krijgen )

[Freee!!]

Webgnome schreef op zondag 18 oktober 2020 @ 13:08:
Ik weet nog niet wat ik ga doen. Aan de ene kant lijkt het overkill om alles op eigen pi's te zetten. Aan de andere kant wat maakt het uit? De kosten zijn te negeren zeker als je her raspberry pi zero's voor gebruikt. (helaas is daar geen ethernet hat meer voor te krijgen )

Het is overkill, één RPi4B kost minder dan een tiental zero's samen en kan minimaal tien verschillende taken aan.

[nero355]

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 18:35:
Beste,

Zonet mijn gateway.config.json aangepast om toestellen die hardcoded DNS hebben toch via Pi-Hole te laten resolven, voordien werkte deze perfect, maar nu aangepast voor VLAN setup, ziet iemand fouten:

code:

{
  "service": {
    "mdns": {
      "repeater": {
        "interface": [
          "eth1.10",
          "eth1.20"
        ]
      }
    },
    "nat": {
      "rule": {
        "1": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.1",
          "inside-address": {
            "address": "10.10.1.5-10.10.1.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.1.5-10.10.1.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "2": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.10",
          "inside-address": {
            "address": "10.10.10.5-10.10.10.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.10.5-10.10.10.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "3": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.20",
          "inside-address": {
            "address": "10.10.20.5-10.10.20.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.20.5-10.10.20.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "4": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.30",
          "inside-address": {
            "address": "10.10.30.5-10.10.30.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.30.5-10.10.30.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "5": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.40",
          "inside-address": {
            "address": "10.10.40.5-10.10.40.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "6": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.50",
          "inside-address": {
            "address": "10.10.50.5-10.10.50.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "7": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.100",
          "inside-address": {
            "address": "10.10.100.5-10.10.100.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.100.5-10.10.100.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "6000": {
          "description": "MASQ DNS requests to LAN",
          "destination": {
            "address": "10.10.1.5-10.10.1.6-10.10.10.5-10.10.10.6-10.10.20.5-10.10.20.6-10.10.30.5-10.10.30.6-10.10.40.5-10.10.40.6-10.10.50.5-10.10.50.6-10.10.100.5-10.10.100.6",
            "port": "53"
          },
          "log": "disable",
          "outbound-interface": "eth1",
          "protocol": "tcp_udp",
          "type": "masquerade"
        }
      }
    }
  }
}

Twee dingen :
- Zet dit soort lange lappen tekst tussen Quote Tags.
- Dit kan je beter in [Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 4 vragen

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 21:10:
Merk nu al een immens verschil op 300, ga het voorlopig zo laten.
Nu heb ik het aangepast in 01-pihole.conf, maar ik maak best zeker nieuwe config file aan hiervoor?
Maar de vraag is gaat deze die dat standaard in 01-pihole.conf overrulen

ed1703 schreef op vrijdag 16 oktober 2020 @ 21:24:
In 01-pihole.conf heb ik het ook hoor.. en ja tijdens een upgrade loop je kans dat je opeens een nieuwe versie hebt. Altijd even een backup maken he en kijken wat ze aangepast hebben. Moet je eigenlijk minimaal wekelijks doen. Naar een NAS oid.

Dit zijn de defaults.. in deze repo zal ook verschijnen als ze iets aanpassen: https://github.com/pi-hol...r/advanced/01-pihole.conf

Naast het feit dat het door het Pi-Hole Team wordt aangeraden is het ook een stuk overzichtelijker om je eigen dingen in één of meerdere aparte config files weg te schrijven

MJV schreef op zaterdag 17 oktober 2020 @ 23:07:
Het duurde even voordat ik doorhad dat mijn unbound niet stuk was maar dat ze daarvoor default poort van 5353 naar 5335 hebben gewijzigd, blijkbaar vanwege een mogelijke clash met de poort voor Avahi. Op het eerste gezicht valt deze wisseling van 3 en 5 ook nog eens niet op. Gelukkig kwam ik er na één reinstall al achter en heb ik niet ook mijn tweede raspberry opnieuw in hoeven te stellen

Ik heb Avahi op mijn Pi disabled, want het scheelt weer een stukje ongewenst Multicast verkeer op mijn netwerk

systemctl status avahi-deamon
systemctl stop avahi-daemon
systemctl disable avahi-daemon

[Webgnome]

Freee!! schreef op zondag 18 oktober 2020 @ 13:22:
[...]

Het is overkill, één RPi4B kost minder dan een tiental zero's samen en kan minimaal tien verschillende taken aan.

Aan de andere kant. Een Zero is een stukje zuiniger en is echt niet heel erg slecht qua performance. Althans voor pihole / unbound is het goed genoeg. Ik denk er nog even over na. Het is ook geen noodzaak want op dit moment werkt het met 1 pi hole / dhcp server ook wel. Wilde alleen dat beide pi holes gebruikt zouden worden.

p.s. hoe zorg je er voor dat beide pi holes up to date blijven qua block/white list etc?

[ed1703]

nero355 schreef op zondag 18 oktober 2020 @ 17:08:
[...]

Naast het feit dat het door het Pi-Hole Team wordt aangeraden is het ook een stuk overzichtelijker om je eigen dingen in één of meerdere aparte config files weg te schrijven

Nouja, in zoverre dat je opties gaat overriden, maar dat is natuurlijk helemaal niet overzichtelijk.
Ik vind pihole ook wat onhandig omdat je met de default vaak niet uitkomt.
Veel beter is om alle mogelijke opties van dnsmasq in de webinterface te verwerken zodat je ook maar 1 configfile nodig hebt en een optie ook maar 1x voorkomt.

[Freee!!]

Webgnome schreef op zondag 18 oktober 2020 @ 17:49:
[...]
Aan de andere kant. Een Zero is een stukje zuiniger en is echt niet heel erg slecht qua performance. Althans voor pihole / unbound is het goed genoeg. Ik denk er nog even over na. Het is ook geen noodzaak want op dit moment werkt het met 1 pi hole / dhcp server ook wel. Wilde alleen dat beide pi holes gebruikt zouden worden.

Zoals ik heb aangegeven, IP-adressen van beide Pi-Holes meegeven.

p.s. hoe zorg je er voor dat beide pi holes up to date blijven qua block/white list etc?

Als ik bij wijze van uitzondering een keer iets handmatig moet doen, doe ik dat gewoon twee keer.

[nero355]

ed1703 schreef op zondag 18 oktober 2020 @ 17:51:
Nouja, in zoverre dat je opties gaat overriden, maar dat is natuurlijk helemaal niet overzichtelijk.
Ik vind pihole ook wat onhandig omdat je met de default vaak niet uitkomt.
Veel beter is om alle mogelijke opties van dnsmasq in de webinterface te verwerken zodat je ook maar 1 configfile nodig hebt en een optie ook maar 1x voorkomt.

Zou leuk zijn, maar dan krijg je weer allerlei overwegingen, zoals hoe vaak je een bepaalde optie moet kunnen toepassen en hoe ver je dus qua flexibiliteit gaat met je WebGUI

Persoonlijk vind ik losse config files helemaal prima, zolang ik die betrouwbaar kan bewaren en dus niet ineens kwijt ben na een upgrade of dat ze ineens geen functie meer hebben, zoals je nog weleens ziet bij andere software!

[ed1703]

nero355 schreef op zondag 18 oktober 2020 @ 17:58:
[...]

Zou leuk zijn, maar dan krijg je weer allerlei overwegingen, zoals hoe vaak je een bepaalde optie moet kunnen toepassen en hoe ver je dus qua flexibiliteit gaat met je WebGUI

De methode die OMV gebruikt is anders prima.
Je krijgt een set defaults, deze kun je aanpassen in de webinterface en wil je extra opties, dan is dit per regel te configureren in het advanced opties tekstvak. In de config staat dan alles wat advanced is keurig netjes in een apart gedeelte.

Persoonlijk vind ik losse config files helemaal prima, zolang ik die betrouwbaar kan bewaren en dus niet ineens kwijt ben na een upgrade of dat ze ineens geen functie meer hebben, zoals je nog weleens ziet bij andere software!

Ik denk dat 70% van de pihole gebruikers niet eens weten dat er dnsmasq draait
Die komen er in een poll met "Welke dns-server-software gebruik u?" niet uit als Pi-Hole er niet bij staat

[nero355]

ed1703 schreef op zondag 18 oktober 2020 @ 18:18:
De methode die OMV gebruikt is anders prima.
Je krijgt een set defaults, deze kun je aanpassen in de webinterface en wil je extra opties, dan is dit per regel te configureren in het advanced opties tekstvak. In de config staat dan alles wat advanced is keurig netjes in een apart gedeelte.

Zoiets heb ik ook weleens in een of andere WebGUI gezien inderdaad

Ik denk dat 70% van de pihole gebruikers niet eens weten dat er dnsmasq draait
Die komen er in een poll met "Welke dns-server-software gebruik u?" niet uit als Pi-Hole er niet bij staat

Juist om die reden denk ik dat er ook nooit een hele uitgebreide WebGUI zal komen, want het moet voor een breed publiek geschikt zijn en zo

[deHakkelaar]

Een handige om alle regeltjes weer te geven voor mogelijke conflicten:

code:

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

[ Voor 11% gewijzigd door deHakkelaar op 18-10-2020 18:24 ]

[deHakkelaar]

Nog een handige, installeer alleen "dnsmasq-base" voor de man pages (geloof maar paar MB's) om alle opties op te zoeken:

code:

sudo apt install dnsmasq-base

code:

pi@ph5:~ $ dpkg -L dnsmasq-base
[..]
/usr/share/man/es/man8
/usr/share/man/es/man8/dnsmasq.8.gz
/usr/share/man/fr
/usr/share/man/fr/man8
/usr/share/man/fr/man8/dnsmasq.8.gz
/usr/share/man/man8
/usr/share/man/man8/dnsmasq.8.gz

code:

pi@ph5:~ $ man dnsmasq
[..]
DESCRIPTION
       dnsmasq is a lightweight DNS, TFTP, PXE, router advertisement and
       DHCP server. It is intended to provide coupled DNS and DHCP  ser‐
       vice to a LAN.
[..]

Geen zorgen ofdat hij start tijdens boot want daarvoor heb je de "dnsmasq" package nodig:

code:

pi@ph5:~ $ apt-file search dnsmasq.service
dnsmasq: /lib/systemd/system/dnsmasq.service

[ed1703]

Vaag...

Pihole 1:

*** [ DIAGNOSING ]: Core version
[i] Core: v5.1.2 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin https://github.com/pi-hole/pi-hole.git (fetch)
origin https://github.com/pi-hole/pi-hole.git (push)
[i] Branch: master
[i] Commit: v5.1.2-0-g6b536b7

*** [ DIAGNOSING ]: Web version
[i] Web: v5.1.1 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin https://github.com/pi-hole/AdminLTE.git (fetch)
origin https://github.com/pi-hole/AdminLTE.git (push)
[i] Branch: master
[i] Commit: v5.1.1-0-ga03d1bd

*** [ DIAGNOSING ]: FTL version
[✓] FTL: v5.2


# pihole -v -l
Invalid Option! Try 'pihole -v --help' for more information.

pihole 2:

*** [ DIAGNOSING ]: Core version
[i] Core: v5.1.2 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin https://github.com/pi-hole/pi-hole.git (fetch)
origin https://github.com/pi-hole/pi-hole.git (push)
[i] Branch: master
[i] Commit: v5.1.2-0-g6b536b7

*** [ DIAGNOSING ]: Web version
[i] Web: v5.1.1 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin https://github.com/pi-hole/AdminLTE.git (fetch)
origin https://github.com/pi-hole/AdminLTE.git (push)
[i] Branch: master
[i] Commit: v5.1.1-0-ga03d1bd

*** [ DIAGNOSING ]: FTL version
[✓] FTL: v5.2


# pihole -v -l
Latest Pi-hole version is v5.1.2
Latest AdminLTE version is v5.1.1
Latest FTL version is v5.2

Pihole 1:

pihole checkout master
Please note that changing branches severely alters your Pi-hole subsystems
Features that work on the master branch, may not on a development branch
This feature is NOT supported unless a Pi-hole developer explicitly asks!
Have you read and understood this? [y/N] y

....
...
# pihole -v -l
Latest Pi-hole version is v5.1.2
Latest AdminLTE version is v5.1.1
Latest FTL version is v5.2

Ok dan... niet teveel over nadenken dan maar he

[Videopac]

Webgnome schreef op zondag 18 oktober 2020 @ 17:49:
[...]


Aan de andere kant. Een Zero is een stukje zuiniger en is echt niet heel erg slecht qua performance. Althans voor pihole / unbound is het goed genoeg. Ik denk er nog even over na. Het is ook geen noodzaak want op dit moment werkt het met 1 pi hole / dhcp server ook wel. Wilde alleen dat beide pi holes gebruikt zouden worden.

p.s. hoe zorg je er voor dat beide pi holes up to date blijven qua block/white list etc?

cron job om vanuit de een de ander bij te werken?

[Workaholic]

Videopac schreef op dinsdag 20 oktober 2020 @ 10:14:
[...]

cron job om vanuit de een de ander bij te werken?

sudo apt-get update && sudo apt full-upgrade in ssh is voldoende toch? Wil hier eigenlijk ook wel een crontab voor maken. Of zijn er nog specifieke raspberry pi update commands? Ik lees hierboven bijvoorbeeld iets over github maar dat lijkt me niet van toepassing wanneer het in je OS packages zit?

[ Voor 27% gewijzigd door Workaholic op 20-10-2020 11:16 ]

[ed1703]

Workaholic schreef op dinsdag 20 oktober 2020 @ 10:54:
[...]


sudo apt-get update && sudo apt full-upgrade in ssh is voldoende toch? Wil hier eigenlijk ook wel een crontab voor maken. Of zijn er nog specifieke raspberry pi update commands? Ik lees hierboven bijvoorbeeld iets over github.

Er staat een cronjob in /etc/cron.d/, oa voor het updaten van de adserving domains.
Wil je ook je eigen lists gelijk houden met een HA-setup, dan zal je toch iets met scp of nfs zelf moeten gaan ontwikkelen. Dat zit er niet in. Je zal dan een script moeten maken die ook kijkt naar de inhoud. Alleen op basis van de modification-time is eigenlijk niet genoeg. Een andere mogelijkheid.. "the hard way" is elke dag simpelweg met scp een copy te maken en FTL reloaden. Zou de aanpassingen dan sowieso nog maar op 1 pi doen.

[Videopac]

Workaholic schreef op dinsdag 20 oktober 2020 @ 10:54:
[...]


sudo apt-get update && sudo apt full-upgrade in ssh is voldoende toch? Wil hier eigenlijk ook wel een crontab voor maken. Of zijn er nog specifieke raspberry pi update commands? Ik lees hierboven bijvoorbeeld iets over github maar dat lijkt me niet van toepassing wanneer het in je OS packages zit?

Ik interpreteerde het als dat het om zijn/haar persoonlijke zwarte en witte lijsten ging.

[Workaholic]

ed1703 schreef op dinsdag 20 oktober 2020 @ 11:19:
[...]

Er staat een cronjob in /etc/cron.d/, oa voor het updaten van de adserving domains.
Wil je ook je eigen lists gelijk houden met een HA-setup, dan zal je toch iets met scp of nfs zelf moeten gaan ontwikkelen. Dat zit er niet in. Je zal dan een script moeten maken die ook kijkt naar de inhoud. Alleen op basis van de modification-time is eigenlijk niet genoeg. Een andere mogelijkheid.. "the hard way" is elke dag simpelweg met scp een copy te maken en FTL reloaden. Zou de aanpassingen dan sowieso nog maar op 1 pi doen.

Ah check - ik begreep jullie inderdaad verkeerd. Ik was opzoek naar het updaten van het OS en niet de blacklists oid.

[TheCeet]

Ik zou graag ipv6 werkende krijgen bij mij thuis.
In mijn Asus AX58u router moet ik dus dnsmasq.postconf aanmaken. Alle info van deze website.

Nu heb ik thuis 2 DNS servers (2 raspberry pi's) draaien.
Hoe vul ik in onderstaande code 2 ipv6 adressen in tussen de haken?

code:

#!/bin/sh
sed -i "s/dhcp-option=lan,option6:23,.*/dhcp-option=lan,option6:23,[<fe80... DNS IPv6 address>]/" $1
echo "dhcp-option=lan,6,<DNS IPv4 address>" >> $1

[deHakkelaar]

TheCeet schreef op woensdag 21 oktober 2020 @ 13:33:
Ik zou graag ipv6 werkende krijgen bij mij thuis.
In mijn Asus AX58u router moet ik dus dnsmasq.postconf aanmaken. Alle info van deze website.

Nu heb ik thuis 2 DNS servers (2 raspberry pi's) draaien.
Hoe vul ik in onderstaande code 2 ipv6 adressen in tussen de haken?

code:

#!/bin/sh
sed -i "s/dhcp-option=lan,option6:23,.*/dhcp-option=lan,option6:23,[<fe80... DNS IPv6 address>]/" $1
echo "dhcp-option=lan,6,<DNS IPv4 address>" >> $1

Dit heeft eigenlijk niks met Pi-hole te maken maar goed:

code:

pi@ph5:~ $ man dnsmasq
[..]
       -O,   --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-en‐
       cap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-
       name>|option6:<opt>|option6:<opt-name>],[<value>[,<value>]]
              Specify different or extra options to DHCP clients. By de‐
              fault,   dnsmasq  sends  some  standard  options  to  DHCP
              clients, the netmask and broadcast address are set to  the
              same  as  the host running dnsmasq, and the DNS server and
              default route are set to the address of the  machine  run‐
              ning  dnsmasq.  (Equivalent  rules apply for IPv6.) If the
              domain name option has been set, that is sent.  This  con‐
              figuration  allows  these  defaults  to  be overridden, or
              other options specified. The option, to  be  sent  may  be
              given as a decimal number or as "option:<option-name>" The
              option numbers are specified  in  RFC2132  and  subsequent
              RFCs. The set of option-names known by dnsmasq can be dis‐
              covered by running "dnsmasq --help dhcp".  For example, to
              set the default route option to 192.168.4.4, do --dhcp-op‐
              tion=3,192.168.4.4  or  --dhcp-option   =   option:router,
              192.168.4.4   and   to  set  the  time-server  address  to
              192.168.0.4, do --dhcp-option = 42,192.168.0.4 or  --dhcp-
              option  =  option:ntp-server,  192.168.0.4 The special ad‐
              dress 0.0.0.0 is taken to mean "the address of the machine
              running dnsmasq".

              Data  types  allowed  are comma separated dotted-quad IPv4
              addresses, []-wrapped IPv6 addresses,  a  decimal  number,
              colon-separated  hex  digits and a text string. If the op‐
              tional tags are given then this option is only  sent  when
              all the tags are matched.
[..]

code:

pi@ph5:~ $ dnsmasq --help dhcp
Known DHCP options:
  1 netmask
  2 time-offset
  3 router
  6 dns-server
[..]

Zoals je kunt lezen kun je "comma separated" waardes/data types opgeven.
De man pages kun je hieronder vinden:
http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

Of alleen "dnsmasq-base" installeren op één van je Pi's voor de man pages en de dnsmasq binary:

deHakkelaar schreef op zondag 18 oktober 2020 @ 18:38:
Nog een handige, installeer alleen "dnsmasq-base" voor de man pages (geloof maar paar MB's) om alle opties op te zoeken:

code:

sudo apt install dnsmasq-base

code:

pi@ph5:~ $ dpkg -L dnsmasq-base
[..]
/usr/share/man/es/man8
/usr/share/man/es/man8/dnsmasq.8.gz
/usr/share/man/fr
/usr/share/man/fr/man8
/usr/share/man/fr/man8/dnsmasq.8.gz
/usr/share/man/man8
/usr/share/man/man8/dnsmasq.8.gz

code:

pi@ph5:~ $ man dnsmasq
[..]
DESCRIPTION
       dnsmasq is a lightweight DNS, TFTP, PXE, router advertisement and
       DHCP server. It is intended to provide coupled DNS and DHCP  ser‐
       vice to a LAN.
[..]

Geen zorgen ofdat hij start tijdens boot want daarvoor heb je de "dnsmasq" package nodig:

code:

pi@ph5:~ $ apt-file search dnsmasq.service
dnsmasq: /lib/systemd/system/dnsmasq.service

[The Eagle]

Korte vraag voordat ik hem toevoeg: iemand bekend met de blacklist van deze gasten
https://www.sunshine.it/d...-pi-hole-finally-video-2/

Sinds de tweede lockdown regelmatig YT aan staan, begin een beetje gallisch te worden van het cocainemodel wat YT me door de strot probeert te duwen

[TheCeet]

The Eagle schreef op donderdag 22 oktober 2020 @ 19:07:
Korte vraag voordat ik hem toevoeg: iemand bekend met de blacklist van deze gasten
https://www.sunshine.it/d...-pi-hole-finally-video-2/

Sinds de tweede lockdown regelmatig YT aan staan, begin een beetje gallisch te worden van het cocainemodel wat YT me door de strot probeert te duwen

YouTube ads valt niet te blokken via pi-hole of bepaalde blocklists

[The Eagle]

Dat helemaal block niet kan was ik achter ja. Maar alle beetjes helpen
Echter voordat ik hier in huis teveel dicht zet de vraag of iemand deze lijst kent en er ervaring mee heeft.
Iets met een vriendin en twee kids en de hel die losbreekt als YT kids het niet meer doet

[Webgnome]

Je kunt natuurlijk ook premium nemen..

[TheCeet]

The Eagle schreef op donderdag 22 oktober 2020 @ 20:10:
Dat helemaal block niet kan was ik achter ja. Maar alle beetjes helpen
Echter voordat ik hier in huis teveel dicht zet de vraag of iemand deze lijst kent en er ervaring mee heeft.
Iets met een vriendin en twee kids en de hel die losbreekt als YT kids het niet meer doet

Gouden raad dan: blijf van alle zogezegde YouTube blocklists... Ze zorgen voor meer problemen dan dat ze effectief iets doen. Lees: video's willen niet laden, voorbeeldprentje wil niet laden, geschiedenis synct niet, etc etc.

Indien het Android toestellen zijn kan je nog zo'n third party app installeren ipv de officiële YT app.
Vanced is het dacht ik dat aangeraden wordt.
https://vancedapp.com/

[Raven]

Weet iemand hoe je Pi-Hole/lighttpd kunt forceren de SSL certificaat te herladen? Hier wordt om de paar maanden automatisch een nieuw Let's Encrypt wildcard certificaat aangemaakt, Apache2 pikt die met een herstart gewoon op, lighttpd vertikt het regelmatig (ondanks meerdere herstarts) en geeft een expired certificaat aan

[deHakkelaar]

Raven schreef op vrijdag 23 oktober 2020 @ 18:45:
Weet iemand hoe je Pi-Hole/lighttpd kunt forceren de SSL certificaat te herladen? Hier wordt om de paar maanden automatisch een nieuw Let's Encrypt wildcard certificaat aangemaakt, Apache2 pikt die met een herstart gewoon op, lighttpd vertikt het regelmatig (ondanks meerdere herstarts) en geeft een expired certificaat aan

Alweer weinig met Pi-hole te maken maar goed
Ik hou van puzzelen

Heb je een certbot config file voor je domein in /etc/letsencrypt/renewal/ of mogelijk ergens anders opgeslagen ?
Mijn Apache setup gebruikt onderstaande hook om apache2 te herstarten na cert renewal:

code:

$ man certbot
[..]
            --post-hook POST_HOOK
                                  Command to be run in a shell after attempting to
                                  obtain/renew certificates. Can be used to deploy
                                  renewed certificates, or to restart any servers that
                                  were stopped by --pre-hook. This is only run if an
                                  attempt was made to obtain/renew a certificate. If
                                  multiple renewed certificates have identical post-
                                  hooks, only one will be run. (default: None)

Een post hook in de certbot config file voor lighttpd kan bv zijn:

code:

post-hook = service lighttpd reload

EDIT: ow en onderstaande kan misschien handig zijn om te zien welk cert wordt aangeboden en "expire date":

code:

curl -Ivk https://<JOUW_DOMEIN>

EDIT2: Zag typo in de "post-hook" regel.
En misschien eerst "restart" proberen ipv "reload".
En als dat goed werkt probeer je "reload" welke minder ingrijpend is en sneller.

[ Voor 10% gewijzigd door deHakkelaar op 23-10-2020 21:38 ]

[Raven]

deHakkelaar schreef op vrijdag 23 oktober 2020 @ 20:22:
[...]


Alweer weinig met Pi-hole te maken maar goed
Ik hou van puzzelen

Ik gebruik een heel lang wekelijks door cron uitgevoerd commando voor het certificaat dat i.c.m. apache al jaren goed werkt:

Bash:

/usr/local/bin/certbot-auto certonly --keep-until-expiring --manual --manual-public-ip-logging-ok --preferred-challenges=dns --manual-auth-hook /home/pi/certificates/certbot-auto-authenticator.sh --manual-cleanup-hook /home/pi/certificates/certbot-auto-cleanup.sh -d domein.nl -d *.domein.nl | mutt -s "Let's Encrypt" -- [e-mail]

waarbij het cleanupscript o.a. apache2 herstart en dit voor Pi-Hole/lighttpd doet:

Bash:

bash -c "cat /etc/letsencrypt/live/domein.nl/privkey.pem /etc/letsencrypt/live/domein.nl/cert.pem | tee /etc/letsencrypt/live/domein.nl/combined.pem"
service lighttpd restart

Het eerste commando wordt afgaand op de datum/tijd van combined.pem wel uitgevoerd, maar als ik die achteraf nogmaals uitvoer (net ff gechecked), pikt lighttpd het nieuwe certificaat ineens wél op Ik zou haast denken dat dat commando dan te snel uitgevoerd wordt en het oude certificaat nog oppikt.

[ed1703]

Raven schreef op zaterdag 24 oktober 2020 @ 10:02:
[...]

Ik gebruik een heel lang wekelijks door cron uitgevoerd commando voor het certificaat dat i.c.m. apache al jaren goed werkt:

Bash:

/usr/local/bin/certbot-auto certonly --keep-until-expiring --manual --manual-public-ip-logging-ok --preferred-challenges=dns --manual-auth-hook /home/pi/certificates/certbot-auto-authenticator.sh --manual-cleanup-hook /home/pi/certificates/certbot-auto-cleanup.sh -d domein.nl -d *.domein.nl | mutt -s "Let's Encrypt" -- [e-mail]

waarbij het cleanupscript o.a. apache2 herstart en dit voor Pi-Hole/lighttpd doet:

Bash:

bash -c "cat /etc/letsencrypt/live/domein.nl/privkey.pem /etc/letsencrypt/live/domein.nl/cert.pem | tee /etc/letsencrypt/live/domein.nl/combined.pem"
service lighttpd restart

Het eerste commando wordt afgaand op de datum/tijd van combined.pem wel uitgevoerd, maar als ik die achteraf nogmaals uitvoer (net ff gechecked), pikt lighttpd het nieuwe certificaat ineens wél op Ik zou haast denken dat dat commando dan te snel uitgevoerd wordt en het oude certificaat nog oppikt.

Maar dat is toch al overschreven?
Wat is het resultaat als je een sleep 1 of sleep 2 er tussen zet?
Is lighttpd uberhaupt wel restarted? Cron is soms nogal nukkig met paden.
Ik zet in elk script #!/bin/bash bovenaan omdat dan ook het PATH= meekomt.

[ Voor 5% gewijzigd door ed1703 op 24-10-2020 10:34 ]

[Raven]

ed1703 schreef op zaterdag 24 oktober 2020 @ 10:32:
[...]

Maar dat is toch al overschreven?

Ja, weer. Het script maakt de voor lighttpd vereiste combined.pem aan, pas nadat ik dat commando gister nogmaals uitvoerde kreeg lighttp ineens in de gaten dat er een nieuwer certificaat is. Daarom vermoed ik dat het commando in het cleanup script misschien te snel uitgevoerd is. Als dat commando helemaal niet (of niet succesvol) uitgevoerd was, had ik dat aan de datum/tijd kunnen zien.

ed1703 schreef op zaterdag 24 oktober 2020 @ 10:32:
Wat is het resultaat als je een sleep 1 of sleep 2 er tussen zet?

Dat is nu lastig te testen, zal het erin zetten en dan wachten tot het certificaat weer bijgewerkt moet worden.

ed1703 schreef op zaterdag 24 oktober 2020 @ 10:32:
Is lighttpd uberhaupt wel restarted? Cron is soms nogal nukkig met paden.

Jep, ook als ik die achteraf nog een paar keer herstart blijft lighttpd klagen over expired certificaat. Tot ik het commando dat privkey.pem en cert.pem combineert in combined.pem, nadat het script dat al had gedaan, opnieuw maar dan met de hand uitvoer.

ed1703 schreef op zaterdag 24 oktober 2020 @ 10:32:
Ik zet in elk script #!/bin/bash bovenaan omdat dan ook het PATH= meekomt.

Dat heb ik ook, had alleen de relevante commando's uit dat script vermeld, de code voor het opruimen van de voor de verificatie aangemaakte DNS records is niet interessant

[ Voor 3% gewijzigd door Raven op 24-10-2020 13:55 ]

[technorabilia]

Mijn Philips TV doet elke seconde een verzoek naar a.root-servers.net. Waarom is mij een raadsel.

Is er nog een manier om a.root-servers.net uit te sluiten van de pihole statistieken (m.a.w. te verbergen)?

[hp-got]

kraades schreef op zaterdag 24 oktober 2020 @ 18:43:
Mijn Philips TV doet elke seconde een verzoek naar a.root-servers.net. Waarom is mij een raadsel.

Is er nog een manier om a.root-servers.net uit te sluiten van de pihole statistieken (m.a.w. te verbergen)?

Misschien doettie dat wel omdat a.root-servers.net onbereikbaar is?

In ieder geval is dat zo vanaf het Freedom netwerk voor het IPv6 adres van a.root-servers.net en j.root-servers.net, en waarschijnlijk ook wel voor andere netwerken die een gedeelte van dezelfde routering gebruiken: klik

Dit is trouwens geen antwoord op je vraag, maar misschien wel een verklaring waarom het gebeurt.

[technorabilia]

@hp-got
Zou best kunnen, maar het liefst negeer ik dit adres geheel.

Nu draait alles om a.root-servers.net:

[MJV]

The Eagle schreef op donderdag 22 oktober 2020 @ 19:07:
Korte vraag voordat ik hem toevoeg: iemand bekend met de blacklist van deze gasten
https://www.sunshine.it/d...-pi-hole-finally-video-2/

Sinds de tweede lockdown regelmatig YT aan staan, begin een beetje gallisch te worden van het cocainemodel wat YT me door de strot probeert te duwen

Ik heb er sinds een re-install nog maar drie; maar opvallend weinig van YT ads. Wel af en toe een filmpje dat niet lijkt te laden (dat is dan de ad), maar dan start de video daarna gewoon.

https://raw.githubusercon...nBlack/hosts/master/hosts
https://mirror1.malwaredomains.com/files/justdomains
https://dbl.oisd.nl/

[hp-got]

kraades schreef op zaterdag 24 oktober 2020 @ 19:19:
@hp-got
Zou best kunnen, maar het liefst negeer ik dit adres geheel.

Nu draait alles om a.root-servers.net:
[Afbeelding]

Je zou het eens kunnen proberen door het a.root-servers.net adres in te voeren onder Settings - API/Web interface in het 'Top Domains / Top Advertisers' blokje.

[deHakkelaar]

Raven schreef op zaterdag 24 oktober 2020 @ 10:02:
[...]

Bash:

bash -c "cat /etc/letsencrypt/live/domein.nl/privkey.pem /etc/letsencrypt/live/domein.nl/cert.pem | tee /etc/letsencrypt/live/domein.nl/combined.pem"
service lighttpd restart

Ik zou bovenstaande ook in een appart scriptje plaatsen (plus sleep).
En die "--post-hook" optie gebruiken om deze aan te roepen eg:

code:

--post-hook /path/to/schript.sh

Die "--manual-cleanup-hook" optie lijkt niet gepast daarvoor:

code:

pi@ph5:~ $ man certbot
[..]
            --post-hook POST_HOOK
                                  Command to be run in a shell after attempting to
                                  obtain/renew certificates. Can be used to deploy
                                  renewed certificates, or to restart any servers that
                                  were stopped by --pre-hook. This is only run if an
                                  attempt was made to obtain/renew a certificate. If
                                  multiple renewed certificates have identical post-
                                  hooks, only one will be run. (default: None)

code:

pi@ph5:~ $ man certbot
[..]
          manual:
            Authenticate through manual configuration or custom shell scripts. When
            using shell scripts, an authenticator script must be provided. The
            environment variables available to this script depend on the type of
            challenge. $CERTBOT_DOMAIN will always contain the domain being
            authenticated. For HTTP-01 and DNS-01, $CERTBOT_VALIDATION is the
            validation string, and $CERTBOT_TOKEN is the filename of the resource
            requested when performing an HTTP-01 challenge. When performing a TLS-
            SNI-01 challenge, $CERTBOT_SNI_DOMAIN will contain the SNI name for which
            the ACME server expects to be presented with the self-signed certificate
            located at $CERTBOT_CERT_PATH. The secret key needed to complete the TLS
            handshake is located at $CERTBOT_KEY_PATH. An additional cleanup script
            can also be provided and can use the additional variable
            $CERTBOT_AUTH_OUTPUT which contains the stdout output from the auth
            script.
[..]
            --manual-cleanup-hook MANUAL_CLEANUP_HOOK
                                  Path or command to execute for the cleanup script
                                  (default: None)

EDIT: oops ik realiseer me net, als je de "certbot" package hebt geinstalleerd, komt deze ook met onderstaande:

code:

pi@ph5:~ $ dpkg -L certbot
/.
/etc
/etc/cron.d
/etc/cron.d/certbot
/etc/letsencrypt
/etc/letsencrypt/cli.ini
/etc/logrotate.d
/etc/logrotate.d/certbot
/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/certbot.service
/lib/systemd/system/certbot.timer
/usr
/usr/bin
/usr/bin/certbot
/usr/share
/usr/share/doc
/usr/share/doc/certbot
/usr/share/doc/certbot/README.rst.gz
/usr/share/doc/certbot/changelog.Debian.gz
/usr/share/doc/certbot/changelog.gz
/usr/share/doc/certbot/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/certbot.1.gz
/usr/bin/letsencrypt
/usr/share/man/man1/letsencrypt.1.gz

code:

pi@ph5:~ $ cat /lib/systemd/system/certbot.service
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

code:

pi@ph5:~ $ cat /lib/systemd/system/certbot.timer
[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

code:

pi@ph5:~ $ systemctl --no-pager --full -a list-timers
NEXT                          LEFT          LAST                          PASSED      UNIT                         ACTIVATES
[..]
Sun 2020-10-25 01:06:39 CEST  3h 53min left n/a                           n/a         certbot.timer                certbot.service
[..]
7 timers listed.

code:

pi@ph5:~ $ systemctl status certbot.service
[..]
   Loaded: loaded (/lib/systemd/system/certbot.service; static; vendor preset: enabled)

code:

pi@ph5:~ $ journalctl -u certbot.service
[..]
Oct 24 04:26:06 ph5 certbot[3820]: Attempting to renew cert ....

Mogelijk gaat dit conflicteren met jou cron setup als de "certbot.service" al het cert heeft vernieuwd en jou cron job dan het niet noodzakelijk acht om opnieuw te vernieuwen en de lighttpd daemon een schop te geven.

[ Voor 195% gewijzigd door deHakkelaar op 24-10-2020 21:14 ]

[technorabilia]

hp-got schreef op zaterdag 24 oktober 2020 @ 19:55:
[...]


Je zou het eens kunnen proberen door het a.root-servers.net adres in te voeren onder Settings - API/Web interface in het 'Top Domains / Top Advertisers' blokje.

Bedankt, ik heb het domain alsook het ip adres van mijn TV uitgesloten. Ik zie het adres en de client (TV) nu niet meer in de lijstjes, maar het aantal queries blijft gewoon oplopen wat alsnog de statistieken vervuilt. Jammer dat het niet totaal wordt genegeerd.

[hp-got]

kraades schreef op zaterdag 24 oktober 2020 @ 20:56:
[...]


Bedankt, ik heb het domain alsook het ip adres van mijn TV uitgesloten. Ik zie het adres en de client (TV) nu niet meer in de lijstjes, maar het aantal queries blijft gewoon oplopen wat alsnog de statistieken vervuilt. Jammer dat het niet totaal wordt genegeerd.

You can't have your cake and eat it too.....

Het enige dat ik kan bedenken is om, als je een Wi-Fi voor je gasten hebt dat niet door Pi-hole bediend wordt, de TV daarop aan te sluiten.
Maar ik heb geen idee hoe jouw netwerk er uit ziet en hoe de TV is aangesloten.
Ik betwijfel of je Pi-hole kan vertellen dat hij request van een bepaald apparaat moet negeren.
Misschien dat ze op discourse iets slims weten: klik

[Kopernikus.1979]

ed1703 schreef op vrijdag 16 oktober 2020 @ 20:07:
[...]

Je kunt de TTL van lokale records die clients moeten hanteren aanpassen via local-ttl=seconden.
Dat zal de client dan dwingen om het record niet eerder weer bij de DNS-server op te vragen, zolang de TTL aan het aftellen is. Deze zou je bv op 300 kunnen zetten oid. Ik zou dit niet te hoog zetten. Geen 86400 bijvoorbeeld, want dat is een hel bij het aanpassen van ipadressen of verhuizen van systemen van vlan naar vlan wat je echt binnen je resolving nodig hebt
Unifi is inderdaad een druk systeem als je dat via DNS doet. Ik heb overigens ook slechte ervaringen met stack van trans-ip. Die pompte m'n statistieken ook flink omhoog. Waarschijnlijk gebruiken die ook een lage TTL. Ook dat is via dnsmasq te overrulen. (min-cache-ttl=)

Ik kom nog even terug op bovenstaande.
Alhoewel het aanpassen van de local-ttl werkt kan het inderdaad voor problemen zorgen als ik bv een domein whitelist, want dan is deze pas beschikbaar na de ingestelde ttl tijd (tenzij men een refresh doet).

Nu dacht ik zou het volgende werken (in een dnsmasq 00-naam.conf file):

host-record=unifihostname,IP adres,TTL

--host-record=[,....],[],[][,]
[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=laptop,laptop.thekelleys.org 1,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.

Op die manier krijgen enkel de host-records die ik definieer de opgelegde TTL.

Mijn vraag dan is moet die host record dan nog in de hosts file blijven staan of niet?
Of misschien beter nog, maak ik voor allemaal host-record lijntjes? Want ik heb bv een stuk of 10 hostnames die resolven naar dezelfde local-ip (reverse proxy), nu hebben die elk 1 lijntje.

Dus dan zoiets:

host-record=hostnameserver,IP adres,TTL
cname=alias1,alias2,alias3

[ Voor 21% gewijzigd door Kopernikus.1979 op 25-10-2020 11:49 ]

[deHakkelaar]

Kopernikus.1979 schreef op zaterdag 24 oktober 2020 @ 22:48:
[...]
Mijn vraag dan is moet die host record dan nog in de hosts file blijven staan of niet?

Nee want dat is dubbel op.
Probeer het zou ik zeggen tweaker

code:

pi@ph5:~ $ dig +nocmd +noall +answer @10.0.0.2 avr.dehakkelaar.nl
avr.dehakkelaar.nl.          2       IN      A       10.0.0.9

De tweede kolom van bovenstaande antwoord is de TTL in secondes.

EDIT: Niet vergeten te herladen als je aanpassingen maakt:

code:

pihole-FTL --test

code:

sudo service pihole-FTL reload

[ Voor 15% gewijzigd door deHakkelaar op 25-10-2020 17:08 ]

[deHakkelaar]

kraades schreef op zaterdag 24 oktober 2020 @ 18:43:
Mijn Philips TV doet elke seconde een verzoek naar a.root-servers.net. Waarom is mij een raadsel.

Is er nog een manier om a.root-servers.net uit te sluiten van de pihole statistieken (m.a.w. te verbergen)?

@kraades , host records aanmaken met zeer hoge TTL is mogelijk voor jou ook een oplossing zoals in onderstaande post wordt omschreven:

Kopernikus.1979 schreef op zaterdag 24 oktober 2020 @ 22:48:
[...]


Ik kom nog even terug op bovenstaande.
Alhoewel het aanpassen van de local-ttl werkt kan het inderdaad voor problemen zorgen als ik bv een domein whitelist, want dan is deze pas beschikbaar na de ingestelde ttl tijd (tenzij men een refresh doet).

Nu dacht ik zou het volgende werken (in dnsmasq conf file):

host-record=unifihostname,IP adres,TTL

--host-record=[,....],[],[][,]
[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=laptop,laptop.thekelleys.org 1,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.

Op die manier krijgen enkel de host-records die ik definieer de opgelegde TTL.

Mijn vraag dan is moet die host record dan nog in de hosts file blijven staan of niet?
Of misschien beter nog, maak ik voor allemaal host-record lijntjes? Want ik heb bv een stuk of 10 hostnames die resolven naar dezelfde local-ip (reverse proxy), nu hebben die elk 1 lijntje.

Dus dan zoiets:

host-record=hostnameserver,IP adres,TTL
cname=alias1,alias2,alias3

Bv een TTL van 24 uur = 86400 seconden:

code:

host-record=a.root-servers.net,198.41.0.4,86400

De TV zou dan moeten wachten totdat de TTL is verstreken en de cached record aanspreken voordat hij weer aan Pi-hole kan vragen.
Dat zal, vermoed ik, de stats in de web GUI veel goeds doen.
Plaats deze "host-record=" regeltjes in een nieuw bestandje (niet in "dnsmasq conf") bv:

code:

/etc/dnsmasq.d/99-mijn-settings.conf

En reload:

code:

pihole-FTL --test

code:

sudo service pihole-FTL reload

[Raven]

deHakkelaar schreef op zaterdag 24 oktober 2020 @ 20:27:
[...]


Ik zou bovenstaande ook in een appart scriptje plaatsen (plus sleep).
En die "--post-hook" optie gebruiken om deze aan te roepen eg:

code:

--post-hook /path/to/schript.sh

Die "--manual-cleanup-hook" optie lijkt niet gepast daarvoor:

Hmm, daar maar eens naar kijken, had die optie volgens mij jaren terug niet gezien op https://certbot.eff.org/d...and-post-validation-hooks

Na het bekijken van de docs, dat zou wel eens de oplossing kunnen zijn en het lijkt er inderdaad op dat manual-cleanup-hook te snel wordt uitgevoerd en dus het oude certificaat nog pakt.

deHakkelaar schreef op zaterdag 24 oktober 2020 @ 20:27:
EDIT: oops ik realiseer me net, als je de "certbot" package hebt geinstalleerd, komt deze ook met onderstaande:

....

Mogelijk gaat dit conflicteren met jou cron setup als de "certbot.service" al het cert heeft vernieuwd en jou cron job dan het niet noodzakelijk acht om opnieuw te vernieuwen en de lighttpd daemon een schop te geven.

Certbot-auto is niet door apt geïnstalleerd, maar los gedownload van https://certbot.eff.org/docs/install.html#certbot-auto , heb dus alleen /usr/local/bin/certbot-auto , geen toebehoren zoals die wat jij noemt.

[Kopernikus.1979]

deHakkelaar schreef op zaterdag 24 oktober 2020 @ 23:25:
[...]

Nee want dat is dubbel op.
Probeer het zou ik zeggen tweaker

code:

pi@ph5:~ $ dig +nocmd +noall +answer @10.0.0.2 avr.dehakkelaar.nl
avr.dehakkelaar.nl.          2       IN      A       10.0.0.9

De tweede kolom van bovenstaande antwoord is de TTL in secondes.

EDIT: Niet vergeten te herladen als je aanpassingen maakt:

code:

pihole-FTL --test

code:

pihole restartdns reload

Alles lijkt goed te werken, enkel het cname lijntje niet.

Kan het zijn dat de Pihole implementatie van dnsmasq geen cnames ondersteunt?

Dus:

host-record=hostname1,10.10.50.50,86400
cname=hostname1,alias1,alias2,alias3

Wat wel werkt:

host-record=hostname1,alias1,alias2,alias3,10.10.50.50,86400

Nog een ander raar fenomeen is dat mijn Ubiquiti USG zijn hostname enkel kan resolven als de hostname ook in mijn hosts file staat, op zich geen probleem gezien host-record de gegevens uit de hosts file overrruled, maar toch raar....

[ed1703]

Kopernikus.1979 schreef op zondag 25 oktober 2020 @ 15:42:
[...]


Kan het zijn dat de Pihole implementatie van dnsmasq geen cnames ondersteunt?

Dus:

host-record=hostname1,10.10.50.50,86400
cname=hostname1,alias1,alias2,alias3

--cname=<cname>,[<cname>,]<target>[,<TTL>]
Return a CNAME record which indicates that <cname> is really <target>. There is a significant limitation on the target; it must be a DNS record which is known to dnsmasq and NOT a DNS record which comes from an upstream server. The cname must be unique, but it is permissible to have more than one cname pointing to the same target. Indeed it's possible to declare multiple cnames to a target in a single line, like so: --cname=cname1,cname2,target

gewoon uit /etc/dnsmasq.d/02-lan.conf

cname=logitech.server.lan,squeezebox.server.lan,lms.server.lan,3600


dig -t A logitech.server.lan

logitech.server.lan. 3600 IN CNAME lms.server.lan.
lms.server.lan. 3600 IN A 10.0.2.43

Je format klopt niet.

[Kopernikus.1979]

ed1703 schreef op zondag 25 oktober 2020 @ 16:09:
[...]


--cname=<cname>,[<cname>,]<target>[,<TTL>]
Return a CNAME record which indicates that <cname> is really <target>. There is a significant limitation on the target; it must be a DNS record which is known to dnsmasq and NOT a DNS record which comes from an upstream server. The cname must be unique, but it is permissible to have more than one cname pointing to the same target. Indeed it's possible to declare multiple cnames to a target in a single line, like so: --cname=cname1,cname2,target

gewoon uit /etc/dnsmasq.d/02-lan.conf

cname=logitech.server.lan,squeezebox.server.lan,lms.server.lan,3600


dig -t A

logitech.server.lan. 3600 IN CNAME lms.server.lan.
lms.server.lan. 3600 IN A 10.0.2.43

Je format klopt niet.

Staat logitech.server.lan in je hosts file of als host-record=logitech.server.lan,10.0.43,3600 ?

[deHakkelaar]

Kopernikus.1979 schreef op zondag 25 oktober 2020 @ 15:42:
[...]
Kan het zijn dat de Pihole implementatie van dnsmasq geen cnames ondersteunt?

Dus:

host-record=hostname1,10.10.50.50,86400
cname=hostname1,alias1,alias2,alias3

EDIT: edje was me weer voor maar toch:

Je hebt de namen verkeerd om:

code:

pi@ph5:~ $ man dnsmasq
[..]
       --cname=<cname>,[<cname>,]<target>[,<TTL>]
              Return a CNAME record which indicates that <cname> is  re‐
              ally  <target>.  There  are significant limitations on the
              target; it must be a DNS name which is  known  to  dnsmasq
              from  /etc/hosts  (or  additional hosts files), from DHCP,
              from --interface-name or from  another  --cname.   If  the
              target  does not satisfy this criteria, the whole cname is
              ignored. The cname must be unique, but it  is  permissible
              to  have  more than one cname pointing to the same target.
              Indeed it's possible to declare multiple cnames to a  tar‐
              get  in a single line, like so: --cname=cname1,cname2,tar‐
              get

              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.

code:

pi@ph5:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
cname=alias1.test,alias2.test,alias3.test,pi.hole

Reload pakt dit niet op merkte ik dus restart de daemon:

code:

pi@ph5:~ $ pihole restartdns
  [✓] Restarting DNS server

code:

pi@ph5:~ $ host alias1.test localhost
Using domain server:
Name: localhost
Address: ::1#53
Aliases:

alias1.test is an alias for pi.hole.
pi.hole has address 10.0.0.4

[ed1703]

Kopernikus.1979 schreef op zondag 25 oktober 2020 @ 16:14:
[...]


Staat logitech.server.lan in je hosts file of als host-record=logitech.server.lan,10.0.43,3600 ?

Nee:

host-record=lms.server.lan,10.0.2.43,3600
cname=logitech.server.lan,squeezebox.server.lan,lms.server.lan,3600

Valt ie?


host-record=host,ip,ttl
cname=alias,alias,host,ttl
uiteraard mag
cname=alias,host,ttl ook.

Het maximum weet ik niet, nooit getest.

[Kopernikus.1979]

deHakkelaar schreef op zondag 25 oktober 2020 @ 16:18:
[...]


EDIT: edje was me weer voor maar toch:

Je hebt de namen verkeerd om:

code:

pi@ph5:~ $ man dnsmasq
[..]
       --cname=<cname>,[<cname>,]<target>[,<TTL>]
              Return a CNAME record which indicates that <cname> is  re‐
              ally  <target>.  There  are significant limitations on the
              target; it must be a DNS name which is  known  to  dnsmasq
              from  /etc/hosts  (or  additional hosts files), from DHCP,
              from --interface-name or from  another  --cname.   If  the
              target  does not satisfy this criteria, the whole cname is
              ignored. The cname must be unique, but it  is  permissible
              to  have  more than one cname pointing to the same target.
              Indeed it's possible to declare multiple cnames to a  tar‐
              get  in a single line, like so: --cname=cname1,cname2,tar‐
              get

              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.

code:

pi@ph5:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
cname=alias1.test,alias2.test,alias3.test,pi.hole

Reload pakt dit niet op merkte ik dus restart de daemon:

code:

pi@ph5:~ $ pihole restartdns
  [✓] Restarting DNS server

code:

pi@ph5:~ $ host alias1.test localhost
Using domain server:
Name: localhost
Address: ::1#53
Aliases:

alias1.test is an alias for pi.hole.
pi.hole has address 10.0.0.4

Ha, ik zie het Thx

[Kopernikus.1979]

ed1703 schreef op zondag 25 oktober 2020 @ 16:19:
[...]

Nee:

host-record=lms.server.lan,10.0.2.43,3600
cname=logitech.server.lan,squeezebox.server.lan,lms.server.lan,3600

Valt ie?


host-record=host,ip,ttl
cname=alias,alias,host,ttl
uiteraard mag
cname=alias,host,ttl ook.

Het maximum weet ik niet, nooit getest.

Als men dus met host-records werkt is de hosts file dus niet meer nodig?
Momenteel staat er dit nog in:

code:

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       pihole

10.10.50.10    unificontrollerhostname

[ Voor 3% gewijzigd door Kopernikus.1979 op 25-10-2020 16:26 ]

[ed1703]

Kopernikus.1979 schreef op zondag 25 oktober 2020 @ 16:23:
[...]


Als men dus met host-records werkt is de hosts file dus niet meer nodig?
Momenteel staat er dit nog in:

code:

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       pihole

Ik loop nooit te rommelen aan systeemfiles. Mogelijk dat @deHakkelaar daar een mening over heeft.
Ik zou het lekker laten staan. Zolang dnsmasq daar niets mee doet hebben je clients op je LAN daar geen nadeel of voordeel van. Je USG heeft die file bijvoorbeeld wel nodig met dnsmasq, daar is de opzet ook wat anders van.

[deHakkelaar]

Kopernikus.1979 schreef op zondag 25 oktober 2020 @ 16:23:
[...]


Als men dus met host-records werkt is de hosts file dus niet meer nodig?
Momenteel staat er dit nog in:

code:

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       pihole

10.10.50.10    unificontrollerhostname

Juist.
De hosts file is grof geschut.
Met die "host-record=" regeltjes kun je specifieker records aanmaken.
Je hosts file ziet er gezond uit:

code:

pi@ph5:~ $ cat /etc/hosts

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       ph5.dehakkelaar.nl  ph5

[Kopernikus.1979]

ed1703 schreef op zondag 25 oktober 2020 @ 16:30:
[...]

Ik loop nooit te rommelen aan systeemfiles. Mogelijk dat @deHakkelaar daar een mening over heeft.
Ik zou het lekker laten staan. Zolang dnsmasq daar niets mee doet hebben je clients op je LAN daar geen nadeel of voordeel van. Je USG heeft die file bijvoorbeeld wel nodig met dnsmasq, daar is de opzet ook wat anders van.

Wat is eigenlijk de reden eigenlijk dat Ubiquiti controller wel in de hosts file moet? Hij staat nochtans ook als host-record en voor de switch & AP's nemen hier genoegen mee maar de USG niet....

[deHakkelaar]

Ow ps. pihole-FTL leest deze hosts file zoiezo default:

code:

pi@ph5:~ $ man dnsmasq
[..]
       Dnsmasq accepts DNS queries and either answers them from a small,
       local, cache or forwards them to a real, recursive,  DNS  server.
       It loads the contents of /etc/hosts so that local hostnames which
       do not appear in the global DNS can be resolved and also  answers
       DNS queries for DHCP configured hosts.

Je kan dit default gedrag uitschakelen als je wilt:

code:

pi@ph5:~ $ man dnsmasq
[..]
       -h, --no-hosts
              Don't read the hostnames in /etc/hosts.

[ed1703]

Kopernikus.1979 schreef op zondag 25 oktober 2020 @ 16:37:
[...]


Wat is eigenlijk de reden eigenlijk dat Ubiquiti controller wel in de hosts file moet? Hij staat nochtans ook als host-record en voor de switch & AP's nemen hier genoegen mee maar de USG niet....

De hostnames van alle dhcp-entry's worden in de host-file weggeschreven en gebruikt voor resolving binnen de controller. Je USG doet dat trouwens en niet je controller.

[ Voor 5% gewijzigd door ed1703 op 25-10-2020 16:44 ]

[Kopernikus.1979]

ed1703 schreef op zondag 25 oktober 2020 @ 16:43:
[...]

De hostnames van alle dhcp-entry's worden in de host-file weggeschreven en gebruikt voor resolving binnen de controller. Je USG doet dat trouwens en niet je controller.

Mijn probleem is het volgende:

Dus mijn controller staat in Pi-Hole, als host-record=unifi.mijndomein,10.10.50.10,3600
Zodra ik in de controller de inform host zet op de unifi.mijndomein dan verliest de USG zijn connectie, de switch & AP's resolven wel. Komt dit doordat de USG niet kan/wil DNS resolving naar PiHole doen? Zelf manueel een set-inform werkt niet. Andere mogelijkheid is voor de USG in gateway.config.json een static record aan te maken ofwel gewoon IP adres ingeven van de controller (kweet kies graag moeilijke weg), hoe staat deze bij jou trouwens?

[deHakkelaar]

Aha, onderstaande herlaad niet de wijzigingen in de config bestanden:

code:

pihole restartdns reload

Maar onderstaande wel:

code:

sudo service pihole-FTL reload

Geen idee waarom daar verschil in is.

[streamnl]

Iemand een idee wat wijsheid is?
Het ging maanden goed maar de laatste tijd minder goed. Ik zie steeds meer reclame.
Bijv. op NOS.nl zie ik voortaan reclame als ik een artikel lees.

In de modem van KPN heb ik de DNS aangepast. En het werkte perfect, elk apparaat wat verbinding maakt met mijn netwerk had geen reclame meer. En nu niet meer.

Alleen als ik op een apparaat zelf de dns handmatig aanpas, lijkt het wel te werken.

Pihole en de raspberry zijn up-to-date.


Edit:

de DHCP-functionaliteit van mijn router compleet uit schakelen en Pi-Hole die taak te laten vervullen geeft geen verschil. Ook niet na het opnieuw opstarten

[ Voor 15% gewijzigd door streamnl op 25-10-2020 17:39 ]

[ed1703]

Kopernikus.1979 schreef op zondag 25 oktober 2020 @ 16:58:
[...]


Mijn probleem is het volgende:

Dus mijn controller staat in Pi-Hole, als host-record=unifi.mijndomein,10.10.50.10,3600
Zodra ik in de controller de inform host zet op de unifi.mijndomein dan verliest de USG zijn connectie, de switch & AP's resolven wel. Komt dit doordat de USG niet kan/wil DNS resolving naar PiHole doen? Zelf manueel een set-inform werkt niet. Andere mogelijkheid is voor de USG in gateway.config.json een static record aan te maken ofwel gewoon IP adres ingeven van de controller (kweet kies graag moeilijke weg), hoe staat deze bij jou trouwens?

Je kunt dnsmasq een beetje gaan verbouwen op de USG (scripts in /config/scripts/post-config.d worden namelijk nooit verwijderd, ook niet met een reboot of upgrade), of je gaat met statische host mappings aan de gang. Dit kan inderdaad met config.gateway.json. Zelf heb ik dnsmasq een beetje zitten aanpassen met een extra configfile in /etc/dnsmasq.d. Ik ben er nog niet achter waarom de USG de pihole met local-dnsrecords negeert.

code:

cat /etc/resolv.conf
nameserver      127.0.0.1
#line generated by /opt/vyatta/sbin/vyatta_update_resolv.pl
domain      mgmt.lan

cat /etc/dnsmasq.conf
server=10.0.2.53
server=10.0.2.153

host unifi.mgmt.lan 10.0.2.53
unifi.mgmt.lan has address 10.0.2.250

host unifi.mgmt.lan 127.0.0.1
Host unifi.mgmt.lan not found: 3(NXDOMAIN)

host nu.nl 127.0.0.1

nu.nl has address 52.84.142.96
nu.nl has address 52.84.142.87
nu.nl has address 52.84.142.29
nu.nl has address 52.84.142.120
nu.nl mail is handled by 0 nu-nl.mail.protection.outlook.com.

code:

USG:~$ mca-ctrl -t dump-cfg
...
                "static-host-mapping": {
                        "host-name": {
                                "setup.ubnt.com": {
                                        "alias": [
                                                "setup"
                                        ],
                                        "inet": [
                                                "192.168.1.1"
                                        ]
                                },
                                "unifi.mgmt.lan": {
                                        "inet": [
                                                "10.0.2.250"
                                        ]
                                }
                        }
                },
...

ping unifi.mgmt.lan
PING unifi.mgmt.lan (10.0.2.250) 56(84) bytes of data.
64 bytes from unifi.mgmt.lan (10.0.2.250): icmp_req=1 ttl=64 time=0.501 ms
64 bytes from unifi.mgmt.lan (10.0.2.250): icmp_req=2 ttl=64 time=0.366 ms

in /etc/dnsmasq.conf staat al unifi
host-record=unifi,10.0.2.250,86400
Dit haalt je USG uit de controller.

[ Voor 20% gewijzigd door ed1703 op 25-10-2020 18:50 ]

[Webgnome]

streamnl schreef op zondag 25 oktober 2020 @ 17:37:
Iemand een idee wat wijsheid is?
Het ging maanden goed maar de laatste tijd minder goed. Ik zie steeds meer reclame.
Bijv. op NOS.nl zie ik voortaan reclame als ik een artikel lees.

In de modem van KPN heb ik de DNS aangepast. En het werkte perfect, elk apparaat wat verbinding maakt met mijn netwerk had geen reclame meer. En nu niet meer.

Alleen als ik op een apparaat zelf de dns handmatig aanpas, lijkt het wel te werken.

Pihole en de raspberry zijn up-to-date.

Welke browser gebruik je? Want het zomaar kunnen zijn dat DoH gebruikt wordt en al sje Pihole daar niet voor hebt geconfigureerd gaat je browser daar dus lekker voorbij.

[streamnl]

Webgnome schreef op zondag 25 oktober 2020 @ 17:39:
[...]


Welke browser gebruik je? Want het zomaar kunnen zijn dat DoH gebruikt wordt en al sje Pihole daar niet voor hebt geconfigureerd gaat je browser daar dus lekker voorbij.

Ikzelf Firefox (iPhone) mijn vrouw Chrome (Android)

Edit: voorheen heeft het wel gewerkt en ik heb niets aangepast

[ Voor 8% gewijzigd door streamnl op 25-10-2020 17:41 ]

[Webgnome]

Via een PC werkt het dan ook niet meer?

[streamnl]

Webgnome schreef op zondag 25 oktober 2020 @ 17:41:
Via een PC werkt het dan ook niet meer?

MacBook vanmiddag wel. Morgen zit ik er meer achter en kan ik beter checken of dit zo blijft

Als ik mijn WiFi uitzet en via WireGuard verbinding heb, werkt het wel zoals het hoort.

Het lijkt iets met de WiFi te maken te hebben.

[fsfikke]

TheCeet schreef op donderdag 22 oktober 2020 @ 20:41:
[...]

Gouden raad dan: blijf van alle zogezegde YouTube blocklists... Ze zorgen voor meer problemen dan dat ze effectief iets doen. Lees: video's willen niet laden, voorbeeldprentje wil niet laden, geschiedenis synct niet, etc etc.

Indien het Android toestellen zijn kan je nog zo'n third party app installeren ipv de officiële YT app.
Vanced is het dacht ik dat aangeraden wordt.
https://vancedapp.com/

Ik heb een paar van de standaard lijsten aan staan, maar die hebben allemaal wel een hoop youtube/googlevideo URL's er in staan. Daardoor heb ik regelmatig dat video's niet goed laden. Is er een bepaalde whitelist entry om dat te voorkomen?

[Webgnome]

fsfikke schreef op zondag 25 oktober 2020 @ 17:51:
[...]

Ik heb een paar van de standaard lijsten aan staan, maar die hebben allemaal wel een hoop youtube/googlevideo URL's er in staan. Daardoor heb ik regelmatig dat video's niet goed laden. Is er een bepaalde whitelist entry om dat te voorkomen?

Youtube gebruikt een hele shitload aan domeinen om video's vanaf te serveren. Dus je zult eigenlijk per keer moeten kijken in je pihole welke er nu weer fout gaat en die dan whitelisten. Uiteindelijk zul je op een punt uitkomen dat er nog wel te doen is. Maar van adds op youtube kom je niet meer af tenzij je premium gebruikt.

[fsfikke]

Webgnome schreef op zondag 25 oktober 2020 @ 18:09:
[...]


Youtube gebruikt een hele shitload aan domeinen om video's vanaf te serveren. Dus je zult eigenlijk per keer moeten kijken in je pihole welke er nu weer fout gaat en die dan whitelisten. Uiteindelijk zul je op een punt uitkomen dat er nog wel te doen is. Maar van adds op youtube kom je niet meer af tenzij je premium gebruikt.

Nee dat snap ik, daarom zoek ik naar een whitelist, geen blocklist Want nu heb ik toch wel ads en daarbovenop nog een slecht werkend Youtube. Dan liever ads en een goed werkend Youtube.

[ Voor 10% gewijzigd door fsfikke op 25-10-2020 18:33 ]

[deHakkelaar]

streamnl schreef op zondag 25 oktober 2020 @ 17:40:
[...]

Ikzelf Firefox (iPhone) mijn vrouw Chrome (Android)

Edit: voorheen heeft het wel gewerkt en ik heb niets aangepast

Veel is dynamisch en verandert waardoor mogelijk ad domeinen nog niet op de blocklists/adlists staan.
Wbt nos.nl, ik zag maar 2 reclame velden en deze waren gemakkelijk te blokkeren door onderstaande domeinen aan de Pi-hole blacklist toe te voegen:

code:

pool-ster.adhese.com
ads-ster.adhese.com
ads.pexi.nl

code:

pi@ph5:~ $ pihole -b pool-ster.adhese.com ads-ster.adhese.com ads.pexi.nl
  [i] Adding pool-ster.adhese.com to the blacklist...
  [i] Adding ads-ster.adhese.com to the blacklist...
  [i] Adding ads.pexi.nl to the blacklist...
  [✓] Reloading DNS lists

code:

pi@ph5:~ $ pihole -q ads.pexi.nl
 Match found in exact blacklist
   ads.pexi.nl

code:

C:\>nslookup ads.pexi.nl
Server:  ph5.dehakkelaar.nl
Address:  10.0.0.4

Name:    ads.pexi.nl
Addresses:  ::
          0.0.0.0

Zie ook onderstaande FAQ:
https://discourse.pi-hole...an-ad-is-coming-from/1522

[ Voor 17% gewijzigd door deHakkelaar op 25-10-2020 19:06 ]

[streamnl]

deHakkelaar schreef op zondag 25 oktober 2020 @ 18:57:
[...]


Veel is dynamisch en verandert waardoor mogelijk ad domeinen nog niet op de blocklists/adlists staan.
Wbt nos.nl, ik zag maar 2 reclame velden en deze waren gemakkelijk te blokkeren door onderstaande domeinen aan de Pi-hole blacklist toe te voegen:

code:

pool-ster.adhese.com
ads-ster.adhese.com
ads.pexi.nl

code:

pi@ph5:~ $ pihole -b pool-ster.adhese.com ads-ster.adhese.com ads.pexi.nl
  [i] Adding pool-ster.adhese.com to the blacklist...
  [i] Adding ads-ster.adhese.com to the blacklist...
  [i] Adding ads.pexi.nl to the blacklist...
  [✓] Reloading DNS lists

code:

pi@ph5:~ $ pihole -q ads.pexi.nl
 Match found in exact blacklist
   ads.pexi.nl

code:

C:\>nslookup ads.pexi.nl
Server:  ph5.dehakkelaar.nl
Address:  10.0.0.4

Name:    ads.pexi.nl
Addresses:  ::
          0.0.0.0

Zie ook onderstaande FAQ:
https://discourse.pi-hole...an-ad-is-coming-from/1522

Thanks, ik zag dat er 2 van de drie al geblocked werden.

Gisteren zag ik ook dat in de Queries log bij (een voorbeeld) mijn vrouw haar GSM, alleen www.google.com en 216.58.202.4.in-addr.arpa staan. Voor de rest niets, terwijl ze toch ook op instagram bezig is geweest,

Ik snap niet waarom Pi-Hole ineens anders reageert. Zit te twijfelen om de hele raspberry opnieuw te installeren.

[streamnl]

Inmiddels een compleet nieuwe sd kaart draaien met Pi-Hole en WireGuard.

DHCP staat uit bij KPN (V10A) en alles loopt via de Pi-Hole. (zoals het altijd gelopen heeft)

Ik zie al mijn apparaten in de dashboard met de juiste ipadres die ik ze gegeven heb.

# Laptop vrouw (Windows) wordt netjes alles geblocked.
# GSM vrouw (android) wordt NIETS geblocked. Ik zie daar heel veel:
www.google.com
connectivitycheck.gstatic.com
android.googleapis.com
Ook al pas ik de DNS bij haar aan, dan blijf ik reclame zien en dezelfde domains in haal log.
Maar geen pinterest ofzo.

# Iphone
Hier moet ik bij de instellingen de DNS handmatig aanpassen. Ik zie hier mijn DNS van de raspberry en 2 andere. Dan werkt het. Via WireGuard, werkt het wel zoals het moet.
# Macbook idem, zoals de Iphone

KPN en de Raspberry zijn up-to-date en herstart.

Wat gaat er fout?

[Freee!!]

streamnl schreef op maandag 26 oktober 2020 @ 12:16:
Inmiddels een compleet nieuwe sd kaart draaien met Pi-Hole en WireGuard.

DHCP staat uit bij KPN (V10A) en alles loopt via de Pi-Hole. (zoals het altijd gelopen heeft)

Ik zie al mijn apparaten in de dashboard met de juiste ipadres die ik ze gegeven heb.

# Laptop vrouw (Windows) wordt netjes alles geblocked.
# GSM vrouw (android) wordt NIETS geblocked. Ik zie daar heel veel:
www.google.com
connectivitycheck.gstatic.com
android.googleapis.com
Ook al pas ik de DNS bij haar aan, dan blijf ik reclame zien en dezelfde domains in haal log.
Maar geen pinterest ofzo.

# Iphone
Hier moet ik bij de instellingen de DNS handmatig aanpassen. Ik zie hier mijn DNS van de raspberry en 2 andere. Dan werkt het. Via WireGuard, werkt het wel zoals het moet.
# Macbook idem, zoals de Iphone

KPN en de Raspberry zijn up-to-date en herstart.

Wat gaat er fout?

Veel Android devices en vooral aps benaderen de Google DNS-servers direct op IP-adres, tenzij je verkeer naar poort 53 onderschept en naar je Pi-Hole doorstuurt, kun je daar weinig aan doen.

[streamnl]

Freee!! schreef op maandag 26 oktober 2020 @ 12:39:
[...]

Veel Android devices en vooral aps benaderen de Google DNS-servers direct op IP-adres, tenzij je verkeer naar poort 53 onderschept en naar je Pi-Hole doorstuurt, kun je daar weinig aan doen.

Raar dat het eerst wel "gewoon" werkte.

Heeft het nut als ik een andere Upstream DNS Servers kies?
En als ik dit aanpas, hoef ik dan alleen de vinkjes te verplaatsen?

[Freee!!]

streamnl schreef op maandag 26 oktober 2020 @ 12:42:
[...]
Raar dat het eerst wel "gewoon" werkte.

Het is een voortschrijdend proces (ik vind het geen verbetering).

Heeft het nut als ik een andere Upstream DNS Servers kies?

Nee, het komt op dit moment gewoon niet bij je Pi-Hole aan.

En als ik dit aanpas, hoef ik dan alleen de vinkjes te verplaatsen?

Dit is een stuk ingewikkelder, je moet op de modem/router alle (UDP) verkeer naar poort 53 behalve dat van de Pi-Hole naar de Pi-Hole omleiden. En het wordt nog wat ingewikkelder als DoH of DoT wordt gebruikt.

[streamnl]

Freee!! schreef op maandag 26 oktober 2020 @ 12:46:
Het is een voortschrijdend proces (ik vind het geen verbetering).

Nee, het komt op dit moment gewoon niet bij je Pi-Hole aan.

Dit is een stuk ingewikkelder, je moet op de modem/router alle (UDP) verkeer naar poort 53 behalve dat van de Pi-Hole naar de Pi-Hole omleiden. En het wordt nog wat ingewikkelder als DoH of DoT wordt gebruikt.

Tju. Dan ben ik bang dat mijn kennis niet toereikend genoeg is.

Zal bij haar ook eens Wireguard installeren en haar 100% hierop laten werken, kijken wat ie dan doet.

Edit: Via WireGuard werkt het wel op haar mobiel. Ik vind het toch raar... Maar ja, voor nu "werkt" het weer.

[ Voor 8% gewijzigd door streamnl op 26-10-2020 15:07 ]

[The Eagle]

streamnl schreef op maandag 26 oktober 2020 @ 12:16:
Inmiddels een compleet nieuwe sd kaart draaien met Pi-Hole en WireGuard.

DHCP staat uit bij KPN (V10A) en alles loopt via de Pi-Hole. (zoals het altijd gelopen heeft)

Ik zie al mijn apparaten in de dashboard met de juiste ipadres die ik ze gegeven heb.

# Laptop vrouw (Windows) wordt netjes alles geblocked.
# GSM vrouw (android) wordt NIETS geblocked. Ik zie daar heel veel:
www.google.com
connectivitycheck.gstatic.com
android.googleapis.com
Ook al pas ik de DNS bij haar aan, dan blijf ik reclame zien en dezelfde domains in haal log.
Maar geen pinterest ofzo.

# Iphone
Hier moet ik bij de instellingen de DNS handmatig aanpassen. Ik zie hier mijn DNS van de raspberry en 2 andere. Dan werkt het. Via WireGuard, werkt het wel zoals het moet.
# Macbook idem, zoals de Iphone

KPN en de Raspberry zijn up-to-date en herstart.

Wat gaat er fout?

Die ben ik ook eens tegengekomen. De vraag is wie de DNS settings uitdeelt aan de devices. Telefoons zijn daar notoir in. Meestal helpt het om het gebruikte wifi netwerk op de telefoon te vergeten, goon een herstart te geven (cache clear) en dan wifi netwerk weer toe te voegen. That is: aangenomen dat je DHCP server de DNS settings aan de devices geeft.

Beetje vergelijkbaar met ipconfig /release, ipconfig /flushdns, ipconfig /renew

[Workaholic]

Kan iemand proberen om smokeping aan de praat te krijgen op een recente Pihole? Ik krijg het maar niet aan de praat, maar moet toegeven dat ik een redelijke linux noob ben.

Heb diverse guides via google geprobeerd maar deze lijken te zijn gebaseerd op oude OS/Pihole versies.

Je zou verwachten dat de apt-get install smokeping package gewoon zou moeten werken (anders zou die niet in de repository zitten toch?).

Krijg geen errors bij de installatie en 192.168.2.4/smokeping/smokeping.cgi geeft :



Zal iets te maken hebben met lighttpds?

Versie:

code:

pi@raspberry01:~ $ sudo uname -r
5.4.51-v7l+

pi@raspberry01:~ $ sudo apt-get update && sudo apt-get upgrade
Geraakt:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
Geraakt:2 http://archive.raspberrypi.org/debian buster InRelease

[ Voor 20% gewijzigd door Workaholic op 26-10-2020 12:58 ]

[streamnl]

The Eagle schreef op maandag 26 oktober 2020 @ 12:52:
[...]

Die ben ik ook eens tegengekomen. De vraag is wie de DNS settings uitdeelt aan de devices. Telefoons zijn daar notoir in. Meestal helpt het om het gebruikte wifi netwerk op de telefoon te vergeten, goon een herstart te geven (cache clear) en dan wifi netwerk weer toe te voegen. That is: aangenomen dat je DHCP server de DNS settings aan de devices geeft.

Beetje vergelijkbaar met ipconfig /release, ipconfig /flushdns, ipconfig /renew

Ik twijfel of het werkt (ik had niets veranderd) maar ik heb dit nog niet geprobeerd.
Zal straks eens proberen, kan nooit kwaad.

[Kopernikus.1979]

deHakkelaar schreef op zondag 25 oktober 2020 @ 00:03:
[...]


@kraades , host records aanmaken met zeer hoge TTL is mogelijk voor jou ook een oplossing zoals in onderstaande post wordt omschreven:


[...]


Bv een TTL van 24 uur = 86400 seconden:

code:

host-record=a.root-servers.net,198.41.0.4,86400

De TV zou dan moeten wachten totdat de TTL is verstreken en de cached record aanspreken voordat hij weer aan Pi-hole kan vragen.
Dat zal, vermoed ik, de stats in de web GUI veel goeds doen.
Plaats deze "host-record=" regeltjes in een nieuw bestandje (niet in "dnsmasq conf") bv:

code:

/etc/dnsmasq.d/99-mijn-settings.conf

En reload:

code:

pihole-FTL --test

code:

sudo service pihole-FTL reload

Ondertussen alles prima werkende voor mijn local hosts.
Echter als ik hetzelfde probeer voor een public host, bv:
host-record=connectivitycheck.gstatic.com,216.58.211.99,86400
Dan werkt dit niet, ofwel negeren de Google devices allemaal de TTL....

[deHakkelaar]

streamnl schreef op zondag 25 oktober 2020 @ 17:37:
de DHCP-functionaliteit van mijn router compleet uit schakelen en Pi-Hole die taak te laten vervullen geeft geen verschil. Ook niet na het opnieuw opstarten

Houdt je er ook rekening mee dat er van alles ge-cached wordt!
Cache in je upstream DNS servers, cache in Pi-hole zelf, cache in je client OS en cache in de apps die je gebruikt.

Installeer eens een "network info" app op die pads/phones om te zien welke DNS servers zijn geconfigureerd via DHCP.
Als je router DHCP doet, installeer dan "nmap" op je Pi-hole host of welk ander Linux systeem:

code:

sudo apt install nmap

En doe een DHCP discovery om te zien welke DNS server(s) je router uitdeelt:

code:

sudo nmap -sU -p67 --script dhcp-discover <ROUTER_IP_ADDRESS>

Als een DNS server wordt weergegeven die niet Pi-holed is zullen er toch advertenties etc worden weergegeven:
https://discourse.pi-hole...e-my-only-dns-server/3376

Heb je voor je LAN gedeelte (dus niet je Internet/WAN gedeelte) IPv6 aan staan/enabled in je netwerk/router settings ?
Dan is het mogelijk dat clients een DNS server van je ISP toegewezen krijgt via IPv6 router discovery:

For IPv6 stateless autoconfiguration, DNS configuration is provided by router advertisements.

https://www.juniper.net/d...-dns-server-overview.html

Ik heb geen zin om een dual stack IPv4 en IPv6 te onderhouden dus heb alles IPv6 gerelateerd, aan de LAN kant, uit geschakeld.
Maar dat is persoonlijk.

EDIT: typo

[ed1703]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 15:39:
[...]


Ondertussen alles prima werkende voor mijn local hosts.
Echter als ik hetzelfde probeer voor een public host, bv:
host-record=connectivitycheck.gstatic.com,216.58.211.99,86400
Dan werkt dit niet, ofwel negeren de Google devices allemaal de TTL....

Wat bedoel je precies met Google Devices? Die host-records settings werken met elke host, public of lan, dat maakt niet uit.Er zijn android en google devices zoals chromecasts die een eigen willetje hebben, daar is ook weinig aan te veranderen als dat om TTL gaat. DNS afdwingen gaat wel, langere TTL niet als het device dit negeert.

dns poisoning is overigens af te raden.

[deHakkelaar]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 15:39:
[...]
Ondertussen alles prima werkende voor mijn local hosts.
Echter als ik hetzelfde probeer voor een public host, bv:
host-record=connectivitycheck.gstatic.com,216.58.211.99,86400
Dan werkt dit niet, ofwel negeren de Google devices allemaal de TTL....

code:

pi@ph5:~ $ dig +nocmd +noall +answer @localhost connectivitycheck.gstatic.com
connectivitycheck.gstatic.com. 285 IN   A       216.58.207.67

code:

pi@ph5:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
host-record=connectivitycheck.gstatic.com,216.58.211.99,86400

code:

pi@ph5:~ $ pihole-FTL --test
dnsmasq: syntax check OK.

code:

pi@ph5:~ $ sudo service pihole-FTL reload
pi@ph5:~ $

code:

pi@ph5:~ $ dig +nocmd +noall +answer @localhost connectivitycheck.gstatic.com
connectivitycheck.gstatic.com. 86400 IN A       216.58.211.99

EDIT: ow ps, reboot die devices ivm cache!

[Freee!!]

deHakkelaar schreef op maandag 26 oktober 2020 @ 15:54:
[...]
Installeer eens een "network info" app op die pads/phones om te zien welke DNS servers zijn geconfigureerd via DHCP.
Als je router DHCP doet, installeer dan "nmap" op je Pi-hole host of welk ander Linux systeem:

code:

sudo apt install nmap

En doe een DHCP discovery om te zien welke DNS server(s) je router uitdeelt:

code:

sudo nmap -sU -p67 --script dhcp-discover <ROUTER_IP_ADDRESS>

Als een DNS server wordt weergegeven die niet Pi-holed is zullen er toch advertenties etc worden weergegeven:
https://discourse.pi-hole...e-my-only-dns-server/3376

Kleine kanttekening: nmap werkt niet lekker als je het draait op hetzelfde IP-adres als de DHCP-server.

[deHakkelaar]

Workaholic schreef op maandag 26 oktober 2020 @ 12:53:
Kan iemand proberen om smokeping aan de praat te krijgen op een recente Pihole? Ik krijg het maar niet aan de praat, maar moet toegeven dat ik een redelijke linux noob ben.

Alweer weinig met Pi-hole te maken!
Als je lighttpd als web backend voor smokeping wilt gebruiken, zal je er rekening mee moeten houden dat Pi-hole al lighttpd heeft ge-configureerd voor eigen gebruik:

code:

pi@ph5:~ $ cat /etc/lighttpd/lighttpd.conf
# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
#
# Lighttpd config for Pi-hole
#
# This file is copyright under the latest version of the EUPL.
# Please see LICENSE file for your rights under this license.

###############################################################################
#     FILE AUTOMATICALLY OVERWRITTEN BY PI-HOLE INSTALL/UPDATE PROCEDURE.     #
# ANY CHANGES MADE TO THIS FILE AFTER INSTALL WILL BE LOST ON THE NEXT UPDATE #
#                                                                             #
#              CHANGES SHOULD BE MADE IN A SEPARATE CONFIG FILE:              #
#                         /etc/lighttpd/external.conf                         #
###############################################################################

server.modules = (
    "mod_access",
    "mod_accesslog",
    "mod_auth",
    "mod_expire",
    "mod_compress",
    "mod_redirect",
    "mod_setenv",
    "mod_rewrite"
)

server.document-root        = "/var/www/html"
server.error-handler-404    = "/pihole/index.php"
server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
server.errorlog             = "/var/log/lighttpd/error.log"
server.pid-file             = "/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80
accesslog.filename          = "/var/log/lighttpd/access.log"
accesslog.format            = "%{%s}t|%V|%r|%s|%b"

index-file.names            = ( "index.php", "index.html", "index.lighttpd.html" )
url.access-deny             = ( "~", ".inc", ".md", ".yml", ".ini" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
[..]

Als je dus de lighttpd config gaat aanpassen voor smokeping, zal je daar rekening mee moeten houden!
Als je niet weet hoe lighttpd te configureren of hoe je verschillende web daemons naast elkaar kunt draaien zou ik afraden om smokeping en Pi-hole op dezelfde host te draaien.
Zowel lighttpd en smokeping hebben een man page die je kunt raadplegen:

code:

man lighttpd

code:

man smokeping

[Kopernikus.1979]

deHakkelaar schreef op maandag 26 oktober 2020 @ 16:03:
[...]

code:

pi@ph5:~ $ dig +nocmd +noall +answer @localhost connectivitycheck.gstatic.com
connectivitycheck.gstatic.com. 285 IN   A       216.58.207.67

code:

pi@ph5:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
host-record=connectivitycheck.gstatic.com,216.58.211.99,86400

code:

pi@ph5:~ $ pihole-FTL --test
dnsmasq: syntax check OK.

code:

pi@ph5:~ $ sudo service pihole-FTL reload
pi@ph5:~ $

code:

pi@ph5:~ $ dig +nocmd +noall +answer @localhost connectivitycheck.gstatic.com
connectivitycheck.gstatic.com. 86400 IN A       216.58.211.99

EDIT: ow ps, reboot die devices ivm cache!

Ja, dit werkt inderdaad.
Maar is de TTL aangepast want daarom was het mij te doen? Om minder request te hebben.

[deHakkelaar]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 17:00:
[...]
Maar is de TTL aangepast want daarom was het mij te doen?

Volgens de dig wel:

deHakkelaar schreef op maandag 26 oktober 2020 @ 16:03:

code:

pi@ph5:~ $ dig +nocmd +noall +answer @localhost connectivitycheck.gstatic.com
connectivitycheck.gstatic.com. 86400 IN A       216.58.211.99

[nero355]

streamnl schreef op zondag 25 oktober 2020 @ 17:40:
Ikzelf Firefox (iPhone) mijn vrouw Chrome (Android)

Edit: voorheen heeft het wel gewerkt en ik heb niets aangepast

Jij hebt niks aangepast, maar de fabrikanten wel, want dat doen ze constant!

iPhone + Firefox ken ik niet echt, maar wat ik wel weet :
- Firefox draait dan op de Safari engine dus check die eens qua DNS en Proxy Settings.
- Kijk ook effe of Apple niet stiekem een of andere eigenwijze DNS aanpassing heeft doorgevoerd!

Android en Chrome kunnen één en al ellende zijn :
- Sommige Android telefoons voegen stiekem 8.8.8.8 en 8.8.4.4 als 2de/3de/4de/enz. DNS Server toe.
- Chrome zit de boel constant te verpesten met elke update zowat en in sommige gevallen zelfs zonder updates, maar aanpassingen die gewoon naar de browser worden gepushed
Wat je daar kan checken via chrome://flags is het volgende :
- QUIC Protocol uitschakelen.
- A-Sync DNS uitschakelen.
- DNS over HTTPS of TLS en dergelijken...
- Zet effe een bak koffie en loop ALLE opties na, want ze zullen ondertussen vast wel iets hebben toegevoegd dat ik nog niet ken!

Wat al deze ellende betreft ben ik er echt helemaal klaar mee!
Mijn volgende telefoon wordt gewoon iets totaal anders buiten de twee grote kwaden om!
Lekker terug naar Ubuntu Touch of zo...

[ed1703]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 17:00:
[...]


Ja, dit werkt inderdaad.
Maar is de TTL aangepast want daarom was het mij te doen? Om minder request te hebben.

Ik wil mij nergens mee bemoeien hoor.. maar je bent nu wel bezig om records van google aan te passen die je niet in beheer hebt he.. dus als google iets aanpast werkt het niet meer.

Vanwaar eigenlijk die honger naar zo'n hoge TTL? Pihole op PI2 doet 500k aan requests per dag met 2 vingers in z'n neus.

[ Voor 12% gewijzigd door ed1703 op 26-10-2020 17:09 ]

[Kopernikus.1979]

deHakkelaar schreef op maandag 26 oktober 2020 @ 17:02:
[...]

Volgens de dig wel:


[...]

Hmmm, ok nog eens testen dan, ik had wel sudo service pihole-FTL reload gedaan maar de devices in kwestie (nvidia shield's/google speaker) niet.

[deHakkelaar]

nero355 schreef op maandag 26 oktober 2020 @ 17:02:
[...]
Android en Chrome kunnen één en al ellende zijn :
- Sommige Android telefoons voegen stiekem 8.8.8.8 en 8.8.4.4 als 2de/3de/4de/enz. DNS Server toe.

Dat is niet Android zelf die dat doet.
De implementatie van bepaalde apps kunnen verkeerd zijn en hardcoded 8.8.8.8/8.8.4.4 gebruiken.

[Kopernikus.1979]

ed1703 schreef op maandag 26 oktober 2020 @ 17:04:
[...]

Ik wil mij nergens mee bemoeien hoor.. maar je bent nu wel bezig om records van google aan te passen die je niet in beheer hebt he.. dus als google iets aanpast werkt het niet meer.

Het enige dat kan gebeuren is dat google zijn ip adres aanpast waardoor de host niet meer resolved maar dat zal ik snel merken als mijn shield's beginnen klagen dat ze geen internet meer hebben...

Wat ik wou bereiken is de TTL value hoger te zetten zodat die devices niet elke 2 seconden een request sturen.

[ed1703]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 17:08:
[...]


Het enige dat kan gebeuren is dat google zijn ip adres aanpast waardoor de host niet meer resolved maar dat zal ik snel merken als mijn shield's beginnen klagen dat ze geen internet meer hebben...

Wat ik wou bereiken is de TTL value hoger te zetten zodat die devices niet elke 2 seconden een request sturen.

Ja, ok, dat snap ik nog, maar vind je het niet veel makkelijker om je cache een TTL mee te geven? Dan heb je dat probleem ook niet en is ook wat netter. Ik heb zelf geen devices waarop dat niet werkt.

[nero355]

deHakkelaar schreef op maandag 26 oktober 2020 @ 17:06:
Dat is niet Android zelf die dat doet.

Oww echt wel!

Of beter gezegd : Helaas wel...

Zat telefoons die dat probleem tegenwoordig ingebouwd hebben staan!
OnePlus, Xiaomi, Samsung, Huawei voordat het hele gezeik begon, enz...

De implementatie van bepaalde apps kunnen verkeerd zijn en hardcoded 8.8.8.8/8.8.4.4 gebruiken.

Dat is inderdaad de nieuwste trend die ik effe vergeten was en inderdaad ook vreselijk irritant begint te worden!

[deHakkelaar]

nero355 schreef op maandag 26 oktober 2020 @ 17:12:
[...]

Oww echt wel!

Of beter gezegd : Helaas wel...

Zat telefoons die dat probleem tegenwoordig ingebouwd hebben staan!
OnePlus, Xiaomi, Samsung, Huawei voordat het hele gezeik begon, enz...

Dat zal dan weegegeven worden als je de "Network info" app installeert voor Android.

EDIT: Ow ps. ik heb een Samsung en alleen de Pi-hole IP wordt weergegeven voor DNS.
In het tweede DNS veldje staat 0.0.0.0

[ Voor 42% gewijzigd door deHakkelaar op 26-10-2020 17:34 ]

[Kopernikus.1979]

ed1703 schreef op maandag 26 oktober 2020 @ 17:11:
[...]

Ja, ok, dat snap ik nog, maar vind je het niet veel makkelijker om je cache een TTL mee te geven? Dan heb je dat probleem ook niet en is ook wat netter. Ik heb zelf geen devices waarop dat niet werkt.

Bedoel je de local-ttl=2 setting?

[ed1703]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 17:17:
[...]


Bedoel je de local-ttl=2 setting?

Nee,

min-cache-ttl=900 oid?

[deHakkelaar]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 17:17:
[...]


Bedoel je de local-ttl=2 setting?

Wijzig deze niet!
Deze is expres laag gehouden zodat wanneer je Pi-hole disabled via de web GUI, dat je dan niet hoeft te wachten totdat de TTL is verstreken.

[Kopernikus.1979]

deHakkelaar schreef op maandag 26 oktober 2020 @ 17:19:
[...]


Wijzig deze niet!
Deze is expres laag gehouden zodat wanneer je Pi-hole disabled via de web GUI, dat je dan niet hoeft te wachten totdat de TTL is verstreken.

Heb ik ook niet gedaan.
Ik heb de TTL aangepast voor al mijn lokale devices via host-record=hostname,IP,TTL

Maar voor de public hostnames zou het dus beter zijn min-cache-ttl aan te passen?

[ed1703]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 17:23:
[...]


Heb ik ook niet gedaan.
Ik heb de TTL aangepast voor al mijn lokale devices via host-record=hostname,IP,TTL

Maar voor de public hostnames zou het dus beter zijn min-cache-ttl aan te passen?

Het is inderdaad niet de bedoeling om records te gaan hijacken.
Moet je helemaal zelf weten natuurlijk, maar min-cache-ttl kan je op max 3600 zetten.
Vanwaar die enorme wens naar hoge TTL's? Je PI doet het allemaal met 2 vingers in z'n neus.

[deHakkelaar]

Kopernikus.1979 schreef op maandag 26 oktober 2020 @ 17:23:
[...]


Heb ik ook niet gedaan.
Ik heb de TTL aangepast voor al mijn lokale devices via host-record=hostname,IP,TTL

Maar voor de public hostnames zou het dus beter zijn min-cache-ttl aan te passen?

Probeer het zou ik zeggen.
Je weet hoe de TTL weer te geven:

deHakkelaar schreef op maandag 26 oktober 2020 @ 16:03:
[...]

code:

pi@ph5:~ $ dig +nocmd +noall +answer @localhost connectivitycheck.gstatic.com
connectivitycheck.gstatic.com. 86400 IN A       216.58.211.99

EDIT: Ow ps. die dig geeft alleen de juiste TTL als de @localhost server authoritative is voor dat domein.
Dus als je zelf host-record= regeltjes aanmaakt.
Als niet authoritative, zul je de TTL zien aftellen naar nul als je de dig een paar keer herhaalt.

[ Voor 16% gewijzigd door deHakkelaar op 26-10-2020 17:30 ]

[nero355]

deHakkelaar schreef op maandag 26 oktober 2020 @ 17:15:
Dat zal dan weegegeven worden als je de "Network info" app installeerd voor Android.

Volgens mij kan dat je dat ook gewoon zien in de instellingen of één van de vele Info/Status varianten die telefoons standaard aan boord hebben, maar soms ook helaas niet...

Wat in ieder geval vaak goed blijkt te werken : Push meerdere keren een DNS Server naar je Clients!
Dus heeft je Router 4 lege vakjes ? Vul ze gewoon allemaal in met hetzelfde IP

EDIT: Ow ps. ik heb een Samsung en alleen de Pi-hole IP wordt weergegeven voor DNS.
In het tweede DNS veldje staat 0.0.0.0

Welk model en Android versie

[streamnl]

Whooo, dat is nog eens veel info die ik morgen een rustig moet nalezen @deHakkelaar en @nero355
Thanks

@deHakkelaar maakt het zoveel uit dat er van alles ge-cached wordt? Voorheen heb ik daar nooit problemen door ondervonden. Tenminste, niet dat ik merkte.

@nero355 , ik heb de laatste maanden zitten kijken om iets te kopen buiten Apple of Google. Maar wat ik zag ,was het toch allemaal net niet. En voor sommige phones heb ik gewoon te weinig kennis.

[deHakkelaar]

nero355 schreef op maandag 26 oktober 2020 @ 17:35:
[...]
Volgens mij kan dat je dat ook gewoon zien in de instellingen of één van de vele Info/Status varianten die telefoons standaard aan boord hebben, maar soms ook helaas niet...

Niet op Android toestellen.
Vroeger (oudere versie) kon je een command terminal openen en onderstaande uitvoeren om DNS servers te zien:

code:

getprop

nero355 schreef op maandag 26 oktober 2020 @ 17:35:
[...]
Welk model en Android versie

Galaxy-a20e
Android 10