[AdGuard Home] Ervaringen & discussie

[Wachten...]

Glassertje schreef op dinsdag 12 maart 2024 @ 07:50:
[...]

Ik heb geen flauw idee wat je allemaal aan het doen bent,

Ik doe genoeg, maar niet het juiste blijkbaar

In AGH zie ik de oorspronkelijke namen die mijn router doorstuurt. Maakt niet uit of ik de naam aanpas in mijn router. Heb er verder weinig mee gedaan. Die instellingen heb ik hier vanuit het forum overgenomen.

Ik heb dus ook overal gezocht en diverse varianten geprobeerd om in te stellen.
Ik heb het nu als volgt. Ik Unifi heb ik een firewall regel aanstaan, waarbij het RFC1918 netwerk Adguard mag bereiken op 192.168.0.95 op de poorten 53 en 5335

Als ik ook verbind met met één van die netwerken, en een ipconfig /all doe, dan zie ik de DNS server van Adguard staan.

In de Unifi heb ik voor alle netwerken verwezen naar de Adguard server



in Upstream DNS servers heb ik dit staan:

code:

127.0.0.1:5335
[/local/]192.168.0.1:53
[/168.192.in-addr.arpa/]192.168.0.1:53

en onder Private reverse DNS servers heb ik dit staan (mijn router)

code:

192.168.0.1

Volgens mij doe ik niks anders dan anderen, maar ik krijg geen namen die in mijn Unifi staan. Sterker nog, ik zie heel veel clients niet.

[Glassertje]

Wachten... schreef op dinsdag 12 maart 2024 @ 08:56:
[...]

Ik doe genoeg, maar niet het juiste blijkbaar

[...]


Ik heb dus ook overal gezocht en diverse varianten geprobeerd om in te stellen.
Ik heb het nu als volgt. Ik Unifi heb ik een firewall regel aanstaan, waarbij het RFC1918 netwerk Adguard mag bereiken op 192.168.0.95 op de poorten 53 en 5335

Als ik ook verbind met met één van die netwerken, en een ipconfig /all doe, dan zie ik de DNS server van Adguard staan.

In de Unifi heb ik voor alle netwerken verwezen naar de Adguard server

[Afbeelding]

in Upstream DNS servers heb ik dit staan:

code:

127.0.0.1:5335
[/local/]192.168.0.1:53
[/168.192.in-addr.arpa/]192.168.0.1:53

en onder Private reverse DNS servers heb ik dit staan (mijn router)

code:

192.168.0.1

Volgens mij doe ik niks anders dan anderen, maar ik krijg geen namen die in mijn Unifi staan. Sterker nog, ik zie heel veel clients niet.

Heb je je router de naam local gegeven? Anders werkt die regel niet. Je kan checken of die regel dan werkt door in het zoekvenster van query log local te typen. Je moet dan verzoeken zien met .local aan het einde.



Ik gebruik geen aparte VLAN enzo, maar wellicht dat andere je kunnen helpen.

[Glassertje]

En is de response tijd van unbound nu inmiddels gezakt?

[Wachten...]

Glassertje schreef op dinsdag 12 maart 2024 @ 09:20:
[...]

Heb je je router de naam local gegeven? Anders werkt die regel niet. Je kan checken of die regel dan werkt door in het zoekvenster van query log local te typen. Je moet dan verzoeken zien met .local aan het einde.


[Afbeelding]

Ik gebruik geen aparte VLAN enzo, maar wellicht dat andere je kunnen helpen.

Zover ik weet maakt dat niet uit, omdat ik deze regel heb die niet naar de domeinnaam kijkt, want met de router de naam "local" geven bedoel je de domeinnaam van het netwerk toch? (Bij de dhcp dns settings)?

code:

[/168.192.in-addr.arpa/]192.168.0.1:53

VLAN ben ik nog niet eens mee bezig geweest, want ik krijg überhaupt de namen niet.

[Wachten...]

Glassertje schreef op dinsdag 12 maart 2024 @ 09:27:
En is de response tijd van unbound nu inmiddels gezakt?

Ja die begint langzaam te zakken.

Ik zie daar nu ook mijn andere IP adressen verschijnen van de VLANS die ik heb ingevoerd in de Private reverse DNS servers

[Glassertje]

Wachten... schreef op dinsdag 12 maart 2024 @ 09:32:
[...]


Zover ik weet maakt dat niet uit, omdat ik deze regel heb die niet naar de domeinnaam kijkt, want met de router de naam "local" geven bedoel je de domeinnaam van het netwerk toch? (Bij de dhcp dns settings)?

code:

[/168.192.in-addr.arpa/]192.168.0.1:53

VLAN ben ik nog niet eens mee bezig geweest, want ik krijg überhaupt de namen niet.

klopt.

btw je kan de poort weglaten achter [/168.192.in-addr.arpa/]192.168.0.1

[ Voor 7% gewijzigd door Glassertje op 12-03-2024 09:40 ]

[Glassertje]

Wachten... schreef op dinsdag 12 maart 2024 @ 09:35:
[...]


Ja die begint langzaam te zakken.

Ik zie daar nu ook mijn andere IP adressen verschijnen van de VLANS die ik heb ingevoerd in de Private reverse DNS servers

Je bent te ongeduldig, waar ken ik dat toch van.

Het zou ook nog kunnen dat je router andere namen doorstuurt naar AGH dan dat je zichtbaar ziet in je router. Maar dat weet ik dus niet. Als je je eraan stoort kun je in AGH onder clientinstellingen zelf een naam instellen. Belangrijkste is dat je ze wel ziet staan natuurlijk.

[ Voor 28% gewijzigd door Glassertje op 12-03-2024 09:38 ]

[Wachten...]

Glassertje schreef op dinsdag 12 maart 2024 @ 09:36:
[...]

klopt.

btw je kan de poort weglaten achter [/168.192.in-addr.arpa/]192.168.0.1

Oke goed om te weten.
Dus als ik het domeinnaam leeg laat in Unifi en het volgende invoer, dan heb ik het in theorie goed ingesteld?

code:

127.0.0.1:5335
[/168.192.in-addr.arpa/]192.168.0.1

Ik heb alleen een vermoeden dat ik daar dus ook mijn VLANS in moet voeren, dus:

code:

127.0.0.1:5335
[/168.192.in-addr.arpa/]192.168.0.1
[/168.192.in-addr.arpa/]192.168.10.1
[/168.192.in-addr.arpa/]192.168.20.1

Weet iemand

Glassertje schreef op dinsdag 12 maart 2024 @ 09:36:
[...]

Je bent te ongeduldig, waar ken ik dat toch van.

Hebben we allemaal last van denk ik

Het zou ook nog kunnen dat je router andere namen doorstuurt naar AGH dan dat je zichtbaar ziet in je router. Maar dat weet ik dus niet. Als je je eraan stoort kun je in AGH onder clientinstellingen zelf een naam instellen. Belangrijkste is dat je ze wel ziet staan natuurlijk.

Ja maar ik wil dus niet allerlei dubbel werk gaan doen. Ik weet inderdaad dat ik namen kan invoeren in Adguard, maar ik houd alles netjes bij in Unifi, en die gegevens zou ik graag terug willen zien in Adguard.

Het gekke is dus alleen met hoe ik alles nu heb ingesteld, dat ik onder settings>> client settings lang niet alles te zien krijg. Ik krijg er een paar te zien van een VLAN en een aantal vanaf mijn default netwerk, maar lang niet alles. Er staat wel overal rDNS achter, en dat is goed. Het gekke is alleen dat het niet de namen zijn die ik in Unifi heb ingevoerd (en ik heb het dan over de standaard "naam" input field in Unifi van alle apparaten.

[Glassertje]

@Wachten... Heb je toevallig de namen van je apparaten aangepast in je Unifi?

[Glassertje]

Je kan toch zien in je log of de verzoeken naar je unbound gaan, of terug naar je Unifi?

code:

[/168.192.in-addr.arpa/]192.168.0.1
[/168.192.in-addr.arpa/]192.168.10.1
[/168.192.in-addr.arpa/]192.168.20.1

[Wachten...]

Glassertje schreef op dinsdag 12 maart 2024 @ 10:02:
@Wachten... Heb je toevallig de namen van je apparaten aangepast in je Unifi?

Ja ik heb alle apparaten in de input field "name" aangepast naar iets "logisch"
Ik ga er vanuit dat er naar die namen gekeken wordt?

[Glassertje]

Wachten... schreef op dinsdag 12 maart 2024 @ 10:04:
[...]


Ja ik heb alle apparaten in de input field "name" aangepast naar iets "logisch"
Ik ga er vanuit dat er naar die namen gekeken wordt?

Ik zie in AGH ook de standaard namen, ipv de namen die ik ze gegeven heb.

[Wachten...]

Glassertje schreef op dinsdag 12 maart 2024 @ 10:04:
Je kan toch zien in je log of de verzoeken naar je unbound gaan, of terug naar je Unifi?

code:

[/168.192.in-addr.arpa/]192.168.0.1
[/168.192.in-addr.arpa/]192.168.10.1
[/168.192.in-addr.arpa/]192.168.20.1

Als ik in de query log kijk van Adguard, dan zie ik bij sommige inderdaad namen staan. Maar ook bij heel veel niet.

[ Voor 18% gewijzigd door Wachten... op 12-03-2024 10:08 ]

[Glassertje]

Wachten... schreef op dinsdag 12 maart 2024 @ 10:08:
[...]


Als ik in de query log kijk van Adguard, dan zie ik bij sommige inderdaad namen staan. Maar ook bij heel veel niet.

[Afbeelding]


[Afbeelding]

Je moet onder antwoord kijken, daar staat de gekozen DNS server.

[Wachten...]

Glassertje schreef op dinsdag 12 maart 2024 @ 10:10:
[...]

Je moet onder antwoord kijken, daar staat de gekozen DNS server.

Bij de meeste zie ik Unbound staan 172.0.0.1:5335
en bij sommige staat er niks.

[Wachten...]

Ik blijf het vooral gek vinden dat ik maar een paar apparaten onder de "client list" heb staan. Er staan er circa 10 in, terwijl ik meer dan 50 apparaten heb in mijn Unifi

[Glassertje]

Wachten... schreef op dinsdag 12 maart 2024 @ 10:23:
Ik blijf het vooral gek vinden dat ik maar een paar apparaten onder de "client list" heb staan. Er staan er circa 10 in, terwijl ik meer dan 50 apparaten heb in mijn Unifi

Dan klopt er iets niet, lijkt me.

Typ arpa in je zoekopdracht en dan kan je het checken.

[Wachten...]

Glassertje schreef op dinsdag 12 maart 2024 @ 10:29:
[...]

Dan klopt er iets niet, lijkt me.

Typ arpa in je zoekopdracht en dan kan je het checken.

[Afbeelding]

Ik krijg daar wel wat binnen, maar lang niet alles, en ik zie ook niet "verwerkt" zoals jij ziet.

[alex3305]

Wachten... schreef op maandag 11 maart 2024 @ 22:13:
[...]

het zegt mij alleen helemaal niks, dus ik neem maar dingen over, maar geen idee waar dat arpa voor staat enz. Ook zie ik bij iedereen weer andere instellingen staan. (dus net andere omschrijvingen).

Dan moet je niet zomaar aanpassingen gaan maken in de voorbeelden van ander. Of klakkeloos de ene na de andere configuratie gaan copy-pasten. Dat is hetzelfde als stront naar de muur gooien, ooit blijft daar wel iets plakken .

Mijn Upstream DNS servers ziet er zo uit:

# Unbound
192.168.1.1:53535
# Internal routing
[//]192.168.1.1
[/lan/]192.168.1.1

De eerste is dus voor Unbound. Mijn Unbound server draait, zoals ik eerder zei, op mijn router. In jouw geval zal hier dan 127.0.0.1:5335 staan. Aangezien daar jouw Unbound server zou draaien.

De tweede en derde entries - comments tellen we niet mee - zijn voor interne routing. De twee forward slashes // is om hosts te resolven zonder domeinnaam, conform documentatie:

An empty domain specification, // has the special meaning of “unqualified names only”, i.e. names without any dots in them, like myhost or router.

En de /lan/ gaat uiteraard over interne .lan domeinen, bijvoorbeeld router.lan of adguard.lan:

❯ dig +short tweakers.net @adguard.lan
213.239.154.31

In mijn Private reverse DNS servers heb ik het volgende staan:

192.168.1.1
[/168.192.in-addr.arpa/]192.168.1.1

Wederom volgens documentatie, want met

Wachten... schreef op maandag 11 maart 2024 @ 22:13:
want volgens de documentatie moet ik dit invoeren

code:

[/in-addr.arpa/]192.168.1.1
[/ip6.arpa/]192.168.1.1

en dan bij de Private reverse DNS servers dit

code:

192.168.1.1

heb je de documentatie niet goed gelezen. Alleen als je specifieke PTR servers wilt gebruiken voor publieke adressen moet je de entries uit het eerste blokje hierboven invoeren. Maar ik neem aan dat je dat niet wilt. Die zijn dus niet nodig.

Voor lokale PTR adressen (reverse DNS) staat er letterlijk dit in de documentatie:

Note that if you want to use that address [het gaat hier over 192.168.7.7] for PTR queries for IP addresses in a locally served network range, for example 192.168.0.0/16, you should add this to the “Private reverse DNS servers” field:

[/168.192.in-addr.arpa/]192.168.7.7

In mijn configuratie staat dan ook:

192.168.1.1
[/168.192.in-addr.arpa/]192.168.1.1

Waarbij de eerste entry dus eigenlijk niet nodig is, maar ik het wel een prettig idee vind.

Je kunt trouwens prima zonder reverse DNS en is dus totaal geen verplichting. Reverse DNS gebruik je om namen bij IP adressen te krijgen. Bijvoorbeeld:

❯ nslookup 192.168.1.1
1.1.168.192.in-addr.arpa        name = router.lan.

In Adguard Home is het vooral handig omdat je dan client namen krijgt te zien in plaats van alleen IP adressen. Bijvoorbeeld:

[Wachten...]

alex3305 schreef op dinsdag 12 maart 2024 @ 10:48:
[...]

Dan moet je niet zomaar aanpassingen gaan maken in de voorbeelden van ander. Of klakkeloos de ene na de andere configuratie gaan copy-pasten. Dat is hetzelfde als stront naar de muur gooien, ooit blijft daar wel iets plakken .

Mijn Upstream DNS servers ziet er zo uit:

# Unbound
192.168.1.1:53535
# Internal routing
[//]192.168.1.1
[/lan/]192.168.1.1

De eerste is dus voor Unbound. Mijn Unbound server draait, zoals ik eerder zei, op mijn router. In jouw geval zal hier dan 127.0.0.1:5335 staan. Aangezien daar jouw Unbound server zou draaien.

De tweede en derde entries - comments tellen we niet mee - zijn voor interne routing. De twee forward slashes // is om hosts te resolven zonder domeinnaam, conform documentatie:


[...]

En de /lan/ gaat uiteraard over interne .lan domeinen, bijvoorbeeld router.lan of adguard.lan:

❯ dig +short tweakers.net @adguard.lan
213.239.154.31

In mijn Private reverse DNS servers heb ik het volgende staan:

192.168.1.1
[/168.192.in-addr.arpa/]192.168.1.1

Wederom volgens documentatie, want met


[...]

heb je de documentatie niet goed gelezen. Alleen als je specifieke PTR servers wilt gebruiken voor publieke adressen moet je de entries uit het eerste blokje hierboven invoeren. Maar ik neem aan dat je dat niet wilt. Die zijn dus niet nodig.

Voor lokale PTR adressen (reverse DNS) staat er letterlijk dit in de documentatie:

Je zal echt gelijk hebben, echter had ik dat ook al geprobeerd, en als je hier op het forum zoekt naar [/168.192.in-addr.arpa/], dan voert iedereen dat in bij Upstream DNS servers. Dus is het gek dat ik de weg kwijt raak?

[...]

In mijn configuratie staat dan ook:

192.168.1.1
[/168.192.in-addr.arpa/]192.168.1.1

Waarbij de eerste entry dus eigenlijk niet nodig is, maar ik het wel een prettig idee vind.

Je kunt trouwens prima zonder reverse DNS en is dus totaal geen verplichting. Reverse DNS gebruik je om namen bij IP adressen te krijgen. Bijvoorbeeld:

❯ nslookup 192.168.1.1
1.1.168.192.in-addr.arpa        name = router.lan.

In Adguard Home is het vooral handig omdat je dan client namen krijgt te zien in plaats van alleen IP adressen. Bijvoorbeeld:
[Afbeelding]

Zoals gezegd probeer ik dus ook van alles, aangezien niks werkt. Ook al voer ik alles in zoals jij aangeeft (en dan wel met eigen IP adressen, dan krijg ik alsnog bijna niks bij de client list te zien. Ik zie nog steeds maar een stuk of 10 clients

Ik heb nu even de domeinnaam leeg gelaten in Unifi en jouw configuratie overgenomen
Upstream DNS servers

code:

# Unbound
192.168.0.1:5335

en bij Private reverse DNS

code:

192.168.0.1
[/168.192.in-addr.arpa/]192.168.0.1

[ Voor 4% gewijzigd door Wachten... op 12-03-2024 13:02 ]

[alex3305]

Wachten... schreef op dinsdag 12 maart 2024 @ 12:40:
[...]

Je zal echt gelijk hebben, echter had ik dat ook al geprobeerd, en als je hier op het forum zoekt naar [/168.192.in-addr.arpa/], dan voert iedereen dat in bij Upstream DNS servers. Dus is het gek dat ik de weg kwijt raak?

Ja. Want dit staat echt heel duidelijk in de documentatie:

NOTE: All upstreams for private ranges must go to the “Private reverse DNS servers” field and not the main “Upstream DNS servers” field. Entering something like [/192.in-addr.arpa/]192.168.8.8 into the main field will have no effect.

En nogmaals, je hebt reverse DNS helemaal niet nodig. Dat is echt optioneel.

Wachten... schreef op dinsdag 12 maart 2024 @ 12:40:
Zoals gezegd probeer ik dus ook van alles, aangezien niks werkt. Ook al voer ik alles in zoals jij aangeeft (en dan wel met eigen IP adressen, dan krijg ik alsnog bijna niks bij de client list te zien. Ik zie nog steeds maar een stuk of 10 clients

Dat je geen clients in de client list ziet is een ander probleem dan dat je upstreams niet goed staan . Dan gebruiken de clients Adguard Home niet. Het kan ook zijn dat hier een vertraging in zit voor sommige clients. Omdat de DNS servers via DHCP worden geüpdatet naar de clients toe.

Wachten... schreef op dinsdag 12 maart 2024 @ 12:40:
[J]ouw configuratie overgenomen
Upstream DNS servers

code:

# Unbound
192.168.0.1:5335

Draait Unbound dan op 192.168.0.1? Want ik dacht dat jij die op dezelfde host als Adguard Home had staan.

Maar niet helemaal mijn configuratie overgenomen . Want je kunt op die manier nog steeds geen lokale hostnames resolven .

[Wachten...]

alex3305 schreef op dinsdag 12 maart 2024 @ 13:26:
[...]

Ja. Want dit staat echt heel duidelijk in de documentatie:

Maar dan voert iedereen dat hier dus verkeerd in?

[...]

En nogmaals, je hebt reverse DNS helemaal niet nodig. Dat is echt optioneel.

Dat weet ik, echter wil ik het wel graag, want ik heb 50+ apparaten standaard (met af en toe andere losse tijdelijke apparaten) en ik wil dit graag beter in kaart krijgen. Ik moet nu iedere keer aan de hand van het ip adres kijken welk apparaat het is.

[...]

Dat je geen clients in de client list ziet is een ander probleem dan dat je upstreams niet goed staan . Dan gebruiken de clients Adguard Home niet. Het kan ook zijn dat hier een vertraging in zit voor sommige clients. Omdat de DNS servers via DHCP worden geüpdatet naar de clients toe.

En daar komt wederom het gekke, als ik met het IoT netwerk verbind en een ipconfig /all doe, dan zie ik toch echt mijn Adguard DNS staat. Het enige probleem is dat niet alle apparaten erin staan.

De vertraging kan het wel verklaren misschien. Ik heb veel apparaten die ik een Vast IP heb gegeven in Unifi en die zelden rebooten. Wellicht duurt het dan een tijdje voordat alles zichtbaar is?


[...]

Draait Unbound dan op 192.168.0.1? Want ik dacht dat jij die op dezelfde host als Adguard Home had staan.

Maar niet helemaal mijn configuratie overgenomen . Want je kunt op die manier nog steeds geen lokale hostnames resolven .

Nee ik had een foutje gemaakt met het kopiëren vanuit mijn post. In de Upstream DNS servers heb ik nu enkel staan

code:

172.0.0.1:5335

En klopt het trouwens dat je voor VLANs extra regels toe moet voegen aan de Private reverse DNS servers? Dus zoals onderstaand:

code:

[/168.192.in-addr.arpa/]192.168.0.1
[/168.192.in-addr.arpa/]192.168.10.1
[/168.192.in-addr.arpa/]192.168.20.1

[alex3305]

Wachten... schreef op dinsdag 12 maart 2024 @ 13:44:
[...]

Maar dan voert iedereen dat hier dus verkeerd in?

Ja.

En daar komt wederom het gekke, als ik met het IoT netwerk verbind en een ipconfig /all doe, dan zie ik toch echt mijn Adguard DNS staat. Het enige probleem is dat niet alle apparaten erin staan.

Dat is toch precies wat ik zeg? Als jij verbind met jouw IoT netwerk dan krijg je sowieso een nieuwe DHCP configuratie toegezonden mét daarin de 'juiste' DNS servers. De apparaten die al verbonden zijn gebruiken echter nog steeds de voor hun bekende informatie. Met name IoT apparaten zullen pas bij het verstrijken van de lease nieuwe informatie opvragen.

Je kunt die apparaten ook handmatig herverbinden, bijvoorbeeld door ze te herstarten. Dan zullen ze, zeer waarschijnlijk, wel de nieuwe informatie ontvangen en gebruiken.

Ik test meestal één device en de rest volgt als de lease (of TTL) verloopt vanzelf. Bij netwerkconfiguratie dien je over het algemeen dus wat geduld te hebben .

Nee ik had een foutje gemaakt met het kopiëren vanuit mijn post. In de Upstream DNS servers heb ik nu enkel staan

code:

172.0.0.1:5335

Dat klopt nog steeds niet . Je zou hier ook aanvullend 8.8.8.8 (Google) in kunnen voeren om in ieder geval zeker te zijn dat jouw apparaten online blijven.

En klopt het trouwens dat je voor VLANs extra regels toe moet voegen aan de Private reverse DNS servers? Dus zoals onderstaand:

code:

[/168.192.in-addr.arpa/]192.168.0.1
[/168.192.in-addr.arpa/]192.168.10.1
[/168.192.in-addr.arpa/]192.168.20.1

Nee. Dan zeg je in feite dat Adguard Home voor reverse DNS op drie hosts moet gaan kijken:

• 192.168.0.1
• 192.168.10.1
• 192.168.20.1

Waarbij de tweede en derde host waarschijnlijk niet eens reageren, laat staan resultaten teruggeven. Wat jij bedoelt is het omgekeerde:

[/0.168.192.in-addr.arpa/]192.168.0.1
[/10.168.192.in-addr.arpa/]192.168.0.1
[/20.168.192.in-addr.arpa/]192.168.0.1

Maar ook dat is onnodig, want met [/168.192.in-addr.arpa/]192.168.0.1 zeg je al dat alle PTR records onder 192.168.0.0/16 (of 192.168.x.x) opgevraagd dienen te worden bij 192.168.0.1. Het is in dit geval onnodig om daar nog een laag in aan te brengen.

[Wachten...]

alex3305 schreef op dinsdag 12 maart 2024 @ 13:58:
[...]

Ja.


[...]

Dat is toch precies wat ik zeg? Als jij verbind met jouw IoT netwerk dan krijg je sowieso een nieuwe DHCP configuratie toegezonden mét daarin de 'juiste' DNS servers. De apparaten die al verbonden zijn gebruiken echter nog steeds de voor hun bekende informatie. Met name IoT apparaten zullen pas bij het verstrijken van de lease nieuwe informatie opvragen.

Je kunt die apparaten ook handmatig herverbinden, bijvoorbeeld door ze te herstarten. Dan zullen ze, zeer waarschijnlijk, wel de nieuwe informatie ontvangen en gebruiken.


Ik test meestal één device en de rest volgt als de lease (of TTL) verloopt vanzelf. Bij netwerkconfiguratie dien je over het algemeen dus wat geduld te hebben .

Net even een paar devices gereconnect vanuit Unifi, maar zie ze nog niet verschijnen in Adguard client lijst. Dan nog maar even meer geduld hebben.

[...]

Dat klopt nog steeds niet . Je zou hier ook aanvullend 8.8.8.8 (Google) in kunnen voeren om in ieder geval zeker te zijn dat jouw apparaten online blijven.

Maar je bedoelt hiermee niet perse dat het fout is, maar dat ik beter een alternatieve erbij kan zetten (zoals het oorspronkelijk stond met 1.1.1.1 erbij?

[...]

Nee. Dan zeg je in feite dat Adguard Home voor reverse DNS op drie hosts moet gaan kijken:

• 192.168.0.1
• 192.168.10.1
• 192.168.20.1

Waarbij de tweede en derde host waarschijnlijk niet eens reageren, laat staan resultaten teruggeven. Wat jij bedoelt is het omgekeerde:

[/0.168.192.in-addr.arpa/]192.168.0.1
[/10.168.192.in-addr.arpa/]192.168.0.1
[/20.168.192.in-addr.arpa/]192.168.0.1

Maar ook dat is onnodig, want met [/168.192.in-addr.arpa/]192.168.0.1 zeg je al dat alle PTR records onder 192.168.0.0/16 (of 192.168.x.x) opgevraagd dienen te worden bij 192.168.0.1. Het is in dit geval onnodig om daar nog een laag in aan te brengen.

Oke duidelijk verhaal. Dat stuk snap ik nu dan eindelijk.
Ik ga hopen dat door de uren/dagen heen er clients bij komen in de lijst. Zo niet dan moet ik opnieuw kijken waar het "probleem ligt"

[alex3305]

Wachten... schreef op dinsdag 12 maart 2024 @ 15:26:
Maar je bedoelt hiermee niet perse dat het fout is, maar dat ik beter een alternatieve erbij kan zetten (zoals het oorspronkelijk stond met 1.1.1.1 erbij?

Nee. Ik zeg letterlijk dat het fout is wat je hebt staan :

Wachten... schreef op dinsdag 12 maart 2024 @ 13:44:
Nee ik had een foutje gemaakt met het kopiëren vanuit mijn post. In de Upstream DNS servers heb ik nu enkel staan

code:

172.0.0.1:5335

Dat moet natuurlijk 127.0.0.1:5335 zijn, niet 172.

Wachten... schreef op dinsdag 12 maart 2024 @ 15:26:
Net even een paar devices gereconnect vanuit Unifi, [...]

Ik ga hopen dat door de uren/dagen heen er clients bij komen in de lijst. Zo niet dan moet ik opnieuw kijken waar het "probleem ligt"

Wat voor clients heb je het dan over? En vaak kun je de configuratie ook op de client zelf controleren.

[Wachten...]

alex3305 schreef op dinsdag 12 maart 2024 @ 16:17:
[...]

Nee. Ik zeg letterlijk dat het fout is wat je hebt staan :


[...]

Dat moet natuurlijk 127.0.0.1:5335 zijn, niet 172.

Omdat je over de Google DNS begon was ik even verkeer aan het denken/kijken. Uiteraard is het 127 en dit staat ook zo in mijn DNS settings excuses

[...]

Wat voor clients heb je het dan over? En vaak kun je de configuratie ook op de client zelf controleren.

Bijvoorbeeld een Ipad, Mijn nest thermostaat, een Nextcloud server etc.
Van een aantal heb ik de boel gereconnect, maar komen nog niet in Adguard. Thuis misschien even geheel een apparaat herstarten om te zien wat dat doet.

En wat bedoel je met op de client zelf controleren? Bij de wifi settings bedoel je dan?

[Villager]

Glassertje schreef op dinsdag 12 maart 2024 @ 09:27:
En is de response tijd van unbound nu inmiddels gezakt?

Ik lees in OPNsense in System>Settings>General het volgende:

"Do not use 'local' as your internal domain name. It is reserved for and will interfere with mDNS (avahi, bonjour, etc.). Use the special-purpose home.arpa domain instead"

[Glassertje]

Villager schreef op dinsdag 12 maart 2024 @ 17:21:
[...]


Ik lees in OPNsense in System>Settings>General het volgende:

"Do not use 'local' as your internal domain name. It is reserved for and will interfere with mDNS (avahi, bonjour, etc.). Use the special-purpose home.arpa domain instead"

Bedankt voor je reactie. Kon niet zo snel iets anders verzinnen Zal het straks even aanpassen.

[Wachten...]

@alex3305

Even een update,
Er staan nu redelijk wat namen in en sommige komen ook overeen met die van Unifi.
Ik mis echter nog een paar apparaten, hoofdzakelijk vanuit een VLAN. Een aantal andere apparaten vanuit dezelfde VLAN zie ik weer wel. Ik heb bijvoorbeeld een Nvidia shield in dezelfde VLAN en een iPad, maar hoe vaak ik ze ook herstart, ik krijg ze niet te zien in de client lijst. Ik heb de lease tijd van dat netwerk ook al even op 3600 seconde gezet, in de hoop dat het eerder ververst zou worden, maar zonder gewenst resultaat.

Hij neemt overigens niet de namen over vanuit Unifi. Ik had gehoopt dat ik exact dezelfde namen zou gaan zien als die ik heb ingesteld in Unifi. Dat gezegd hebbende zie ik nu al wel meer als dat ik eerste zag, dus we zijn enigszins goed op weg

Bedankt voor alle hulp tot nu toe.

Mocht je nog suggesties hebben voor de andere "problemen" dan hoor ik het graag. Ik ga ook nog even verder zoeken.

[alex3305]

Wachten... schreef op dinsdag 12 maart 2024 @ 20:25:
Een aantal andere apparaten vanuit dezelfde VLAN zie ik weer wel. Ik heb bijvoorbeeld een Nvidia shield in dezelfde VLAN en een iPad, maar hoe vaak ik ze ook herstart, ik krijg ze niet te zien in de client lijst.

Wie zegt er dat er een lease renewal plaatsvindt als je een een client reconnect? Dat hoeft helemaal niet. Heb gewoon even geduld. Kijk het even aan tot morgen. En als het dan nog niet werkt, kun je altijd nog gaan uitzoeken. Voor iemand die @Wachten... als username hebt ben je echt behoorlijk ongeduldig.

Daarnaast gaat het om DNS requests, niet om verbindingen. Het kan ook zo maar zo zijn dat de apparaten zelf nog een cache hebben. En, zoals ik al eerder zei, controleer de settings op je iPad en Shield. Want je kunt wel gaan gissen waarom het niet werkt, maar ook even de netwerkinformatie raadplegen. Vergeet daarnaast ook niet dat DNS ook niet werkt als je VPN aan hebt staan.

Ik heb de lease tijd van dat netwerk ook al even op 3600 seconde gezet, in de hoop dat het eerder ververst zou worden, maar zonder gewenst resultaat.

Dat heeft vaak geen zin. Want de client had al een geldige lease .

Hij neemt overigens niet de namen over vanuit Unifi. Ik had gehoopt dat ik exact dezelfde namen zou gaan zien als die ik heb ingesteld in Unifi.

Dat zou wel moeten. Je hebt, neem ik aan, wel de twee vinkjes onder Private reverse DNS servers aan staan? Namelijk:

• Use private reverse DNS resolvers
• Enable reverse resolving of clients' IP addresses

[TheCeet]

@Wachten...
Ik gebruik atm geen AGH meer, maar ivm Unbound had ik in de config file volgende nog toegevoegd:

code:

cache-min-ttl: 0
serve-expired: yes
msg-cache-size: 128m
rrset-cache-size: 256m

Mocht je dit aanpassen, Unbound proces uiteraard herstarten om settings toe te passen.

Ik geloof dat ik nog in de settings, AdGuard Cache uit had staan.
Mijn gemiddelde ms kwam soms tot 1ms of max 5ms (afhankelijk van welk device vebonden was).
Zoals je ook aanhaalt is er in jouw netwerk een device die zeer traag response geeft. Ik had hier ook 'last' van in mijn netwerk.

Ik draaide Dietpi OS op Pi4 bedraad via UTP POE.

[Wachten...]

alex3305 schreef op dinsdag 12 maart 2024 @ 21:58:
[...]

Wie zegt er dat er een lease renewal plaatsvindt als je een een client reconnect? Dat hoeft helemaal niet. Heb gewoon even geduld.

Ik heb geforceerd dat de apparaten een nieuw IP adres krijgen, en heb de apparaten herstart en van sommige (in hoeverre het kon) de cache van de netwerk settings geleegd.
Ik had denk ik toch echt al wel iets moeten zien denk ik.
Ook zie ik nog steeds geen namen verschijnen zoals ze in mijn Unifi vermeld staan. Ik zie wel wat namen, maar dat zijn niet de namen die ik in Unifi heb staan.

Kijk het even aan tot morgen. En als het dan nog niet werkt, kun je altijd nog gaan uitzoeken. Voor iemand die @Wachten... als username hebt ben je echt behoorlijk ongeduldig.

Ik zal een aanvraag doen om mijn naar te veranderen naar "ongeduldig"
Nee maar met troubleshooten heb ik geen zin om 24 uur te wachten en om te kijken of iets werkt. Ik wil het toch kunnen forceren om te zien of iets werkt, dat is niet gek toch?

Daarnaast gaat het om DNS requests, niet om verbindingen. Het kan ook zo maar zo zijn dat de apparaten zelf nog een cache hebben. En, zoals ik al eerder zei, controleer de settings op je iPad en Shield. Want je kunt wel gaan gissen waarom het niet werkt, maar ook even de netwerkinformatie raadplegen. Vergeet daarnaast ook niet dat DNS ook niet werkt als je VPN aan hebt staan.

Zoals gezegd heb ik de dus geforceerd een nieuw ip adres gegeven aan de apparaten, zoveel mogelijk gewist qua cache etc. en zelfs de router en Adguard opnieuw opgestart. Mij lijkt dat er ik ergens wel iets met gaan zien dan toch?

[...]

Dat heeft vaak geen zin. Want de client had al een geldige lease .

Zie eerdere opmerking

[...]

Dat zou wel moeten. Je hebt, neem ik aan, wel de twee vinkjes onder Private reverse DNS servers aan staan? Namelijk:

• Use private reverse DNS resolvers
• Enable reverse resolving of clients' IP addresses

Ja die staan beide aan. Ik heb daar dus dit staat bij Private reverse DNS, met daaronder die 2 vinkjes aan "use private reverse DNS resolvers" en "Enable reverse resolving of client IP addresses"

code:

192.168.0.1
[/168.192.in-addr.arpa/]192.168.0.1

[Wachten...]

TheCeet schreef op woensdag 13 maart 2024 @ 08:50:
@Wachten...
Ik gebruik atm geen AGH meer, maar ivm Unbound had ik in de config file volgende nog toegevoegd:

code:

cache-min-ttl: 0
serve-expired: yes
msg-cache-size: 128m
rrset-cache-size: 256m

Mocht je dit aanpassen, Unbound proces uiteraard herstarten om settings toe te passen.

Ik geloof dat ik nog in de settings, AdGuard Cache uit had staan.
Mijn gemiddelde ms kwam soms tot 1ms of max 5ms (afhankelijk van welk device vebonden was).
Zoals je ook aanhaalt is er in jouw netwerk een device die zeer traag response geeft. Ik had hier ook 'last' van in mijn netwerk.

Ik draaide Dietpi OS op Pi4 bedraad via UTP POE.

Ik moet zeggen dat nu ik enkel even Unbound als upstream heb, dan de cijfers wat beter zijn.
Ik heb gisteren de cache gewist van alles, de de afgelopen 12 uur geeft hij als gemiddelde 7ms aan voor de Unbound upstream server. Zoals gezegd heb ik dus nog geen secundaire upstream servers erbij staan. Dat doe ik later nog.

Mijn volgende uitdaging is dus om de namen van Unifi te krijgen in Adguard

[ronaldtb]

Wachten... schreef op woensdag 13 maart 2024 @ 09:28:
[...]


Ik moet zeggen dat nu ik enkel even Unbound als upstream heb, dan de cijfers wat beter zijn.
Ik heb gisteren de cache gewist van alles, de de afgelopen 12 uur geeft hij als gemiddelde 7ms aan voor de Unbound upstream server. Zoals gezegd heb ik dus nog geen secundaire upstream servers erbij staan. Dat doe ik later nog.

Mijn volgende uitdaging is dus om de namen van Unifi te krijgen in Adguard

Ik krijg dat ook voor meerdere apparaten niet voor elkaar.
Alle apparaten waarvan mijn Experia Box een Hostname kan achterhalen worden netjes weergegeven in de Client List.
Maar bijvoorbeeld bij al onze iPads is (volgens mijn Experia Box) de Hostname gelijk aan het MAC adres. Die heb ik bij mijn Experia een 'Friendly Name' gegeven, maar die naam wordt niet meegestuurd.
Die komen dus in AdGuard Home ook zonder naam in de lijst, tenzij ik er een Persistent Client van maak.

[Wachten...]

ronaldtb schreef op woensdag 13 maart 2024 @ 10:13:
[...]


Ik krijg dat ook voor meerdere apparaten niet voor elkaar.
Alle apparaten waarvan mijn Experia Box een Hostname kan achterhalen worden netjes weergegeven in de Client List.
Maar bijvoorbeeld bij al onze iPads is (volgens mijn Experia Box) de Hostname gelijk aan het MAC adres. Die heb ik bij mijn Experia een 'Friendly Name' gegeven, maar die naam wordt niet meegestuurd.
Die komen dus in AdGuard Home ook zonder naam in de lijst, tenzij ik er een Persistent Client van maak.

Ja ik kwam er dus ook achter dat het over de hostname gaat en niet over de "friendly name"
Blijkbaar kan Adguard alleen de Hostname overnemen en niet de "friendly name"
Ik snap alleen de logica hier niet van, want heel veel apparaten geven als hostname een letter en/of cijferreeks en niet een logische naam. Ik zie het nut er tot nu toe dus nog niet van in. "friendly names" lijkt mij veel logischer, maar ik weet niet of dat technisch mogelijk is.

Dat gezegd hebbende lijkt alles dus wel te werken nu, want alle hostnames die ik zie in Unifi, die zie ik ook in Adguard. Echter mis ik nog steeds apparaten in mijn client lijst, wat ik erg gek blijf vinden.

[alex3305]

Adguard Home gebruikt de gegevens van de Reverse DNS server die je hebt opgegeven. Ik krijg gewoon netjes de hostnames die ik bij de statische DHCP leases heb ingevoerd op mijn ASUS router. Wat een 'friendly name' is weet ik niet.

[Wachten...]

alex3305 schreef op woensdag 13 maart 2024 @ 21:56:
Adguard Home gebruikt de gegevens van de Reverse DNS server die je hebt opgegeven. Ik krijg gewoon netjes de hostnames die ik bij de statische DHCP leases heb ingevoerd op mijn ASUS router. Wat een 'friendly name' is weet ik niet.

In Unifi kan ik alle apparaten hernoemen (niet de hostname) echter komen die "friendly names" niet in Adguard. Dit had ik wel gehoopt, want de hostnames van apparaten raken vaak kant noch wal

[ronaldtb]

alex3305 schreef op woensdag 13 maart 2024 @ 21:56:
Adguard Home gebruikt de gegevens van de Reverse DNS server die je hebt opgegeven. Ik krijg gewoon netjes de hostnames die ik bij de statische DHCP leases heb ingevoerd op mijn ASUS router. Wat een 'friendly name' is weet ik niet.

Een 'friendly name' is precies dat. Een vriendelijke, herkenbare naam die je kan toewijzen aan apparaten die anders met een algemene of onherkenbare hostname (bv het MAC adres) in het overzicht met clients staan.
Wellicht is dit vergelijkbaar met wat jij doet met de statische DHCP leases. De Experia Box 12 is niet erg geavanceerd, zeker niet met de geïnstalleerde firmware.

[alex3305]

Ik begrijp uiteraard wel het concept friendly name, maar in de context van DNS bestaat dit natuurlijk niet. Ik geef mijn apparaten met een statische DHCP lease simpelweg een andere hostname. Dan kan ik deze herkennen.

Maar als je dit in Adguard Home wilt, kun je een dergelijke configuratie ook instellen onder Client Settings.

[alex3305]

Afgelopen week heb ik ook Unbound draaien. Initieel alleen op mijn router, maar nu ook als Docker container naast beide Adguard Home instanties. Sowieso omdat deze machines iets meer power hebben, maar dat lijkt vooralsnog niet uit te maken. Hiervoor gebruikte ik Google en Quad9 DNS over TLS. Met een gemiddelde response tijd van respectievelijk 18ms en 10ms.

Sinds ik Unbound gebruik is mijn processing time op mijn primaire installatie van 0.6ms naar 2ms gegaan. En op mijn secundaire instantie zit de processing time nu op 3ms gemiddeld. Heel veel wordt vanuit cache geserveerd, maar een aantal requests duren echt bijzonder lang. Daardoor staat de gemiddelde response time van Unbound boven de 30ms. Ik ben nog niet zeker of ik deze setup zo aanhoudt of dat ik toch bijvoorbeeld Quad9 nog toevoeg.

[cadsite]

Ik heb hier al jaren AGH naar volle tevredenheid draaien op een Raspberry pi 3b.
Maar een paar dagen geleden leek het om zeep te zijn.

AGH stond aan, de blocklist van oisd was actueel en geladen en toch werd er niets tegen gehouden.

Zoeken op de fritzbox gaf geen oplossing en de querry's verliepen netjes via de AGH, maar niets werd er geblokkeerd.

Tot ik er aan dacht dat ik een dag ervoor een app op mijn android had gezet:
https://play.google.com/s...ard_home_manager&hl=en_US

Ik heb een gelijkaardige app op mijn ipdad staan en daar liep alles zoals het hoort. Je kan uitzetten op de ipad en aanzetten op de PC.

Maar bij de android app liep het mis. Als ik daarin de blokkeringen uit zet kan ik op PC of ipad doen wat ik wil, de blokkering blijft uit staan.

Ik wilde het hier even melden zodat anderen hier ook niet uren op zitten te zoeken terwijl het iets heel onnozel is.

[alex3305]

@cadsite Goede vondst. Maar ik zou sowieso niet zo happig zijn om dergelijke onofficiële apps te installeren. De web UI doet het bij prima, ook op de telefoon. En daarnaast heb ik Adguard Home ook in Home Assistant zitten.

[alex3305]

alex3305 schreef op zaterdag 16 maart 2024 @ 11:00:
Sinds ik Unbound gebruik is mijn processing time op mijn primaire installatie van 0.6ms naar 2ms gegaan. En op mijn secundaire instantie zit de processing time nu op 3ms gemiddeld. Heel veel wordt vanuit cache geserveerd, maar een aantal requests duren echt bijzonder lang. Daardoor staat de gemiddelde response time van Unbound boven de 30ms. Ik ben nog niet zeker of ik deze setup zo aanhoudt of dat ik toch bijvoorbeeld Quad9 nog toevoeg.

Inmiddels een weekje verder en mijn gemiddelden zijn weer fors gedaald. Mijn primaire AdGuard Home instantie heeft nu een gemiddelde response tijd van rond de 1ms, en mijn secundaire instantie rond de 3.5ms. Ik heb wel naast Unbound op mijn router nu ook Unbound als Docker container naast beide AdGuard instanties draaien.

Uiteindelijk ben ik dus best tevreden en houd ik het voorlopig zo .

[Jazco2nd]

@alex3305 welk Unbound image gebruik je? En wat is je OS waarop Docker draait? Heb je de ingebouwde resolver van je OS uitgezet?

Heb je Unbound cache wel uitgeschakeld? Zodat je alleen Adguard Home cache gebruikt? Die kan je immers in een UI beheren, minder black box..

[ Voor 4% gewijzigd door Jazco2nd op 27-03-2024 21:36 ]

[alex3305]

Jazco2nd schreef op woensdag 27 maart 2024 @ 21:32:
@alex3305 welk Unbound image gebruik je?

Ik gebruik op mijn applicatie nodes het klutchell/unbound image. Deze was eenvoudig in gebruik en acteert voor zover ik kan zien netjes als recursive resolver. Ik had ook nog getest met mvance/unbound maar die gebruikt out of the box Cloudflare DNS. Wat volgens mij het nut van Unbound teniet doet .

Op mijn ASUS Router gebruik ik Unbound uit amtm.

En wat is je OS waarop Docker draait?

Ik draai een stack op Debian en Unraid. Op Unraid, mijn primaire server, heb ik AdGuard Home met Unbound staan, terwijl ik op mijn secundaire, Debian server tevens AdGuard Home Sync deploy. Zodat de instellingen van de primaire AdGuard Home wordt overgenomen.

Mocht er interesse zijn kan ik eventueel ook de Compose bestanden delen.

Heb je de ingebouwde resolver van je OS uitgezet?

Ik snap de vraag denk ik niet helemaal. Maar mijn primaire server gebruikt mijn router als DNS en mijn secundaire host is afhankelijk van de primaire server voor DNS.

Heb je Unbound cache wel uitgeschakeld? Zodat je alleen Adguard Home cache gebruikt? Die kan je immers in een UI beheren, minder black box..

Dat is een goede tip. Dat heb ik niet gedaan. Ik ga nu uit van zowel de Unbound én AdGuard Home cache. Misschien is het nog wel aardig om een van beide uit te zetten. Waarbij het inderdaad logisch is om de Unbound cache uit te schakelen .

Edit: Even wat zitten zoeken en daar kom ik o.a. bij deze post uit, waarin staat dat zowel Unbound als AdGuard Home toch nét andere manier van cache hebben. Dus ik laat het nu zoals het is .

[ Voor 7% gewijzigd door alex3305 op 28-03-2024 10:45 ]

[BasHouse]

Ik heb hem al een tijdje draaien op een RaspberryPi 4, merk er bijna niks van behalve dan dat ik sommige links wel kan aanklikken maar dat ik dan niet op de doelpagina kom. Uiteraard omdat er een adware link tussen zit. Ik zie dit niet als een probleem. Wel als een wakeup call. En wat ik vooral heel erg merk is dat ik nauwelijks word lastig gevallen met reclame en popups. En natuurlijk staat Tweakers.net in mn whitelist

[Glassertje]

Giseren was AdGuard Home 0.107.47 gereleased. Een uur geleden is er weer een nieuwe versie AdGuard Home v0.107.48

[Mich]

Aan de hand van de berichten op de laatste pagina ook eens naar de response tijden gekeken. Als ik met DNS over TLS servers direct uit AGH werk dan is de responsetijd 9-12 msec.

Echter gebruik ik ook opnsense met unbound. Als ik mijn verzoeken via unbound laat lopen kom ik rond de 80 msec uit. Nu moet ik alleen nog uitzoeken of dit nou komt door opnsense of door (verkeerde) unbound instellingen. Ik gebruik in unbound 3 DNS over TLS servers. Als ik deze uitzet maakt het niet veel verschil in tijd.

Misschien maar eens een unbound in een docker draaien om te zien wat dat doet met de tijden.

edit: Ik lees een guide van iemand die AGH met Unbound installeert en die daar zie ik op het plaatje ook 84 msec. Misschien gaat het gewoon niet sneller.

[ Voor 11% gewijzigd door Mich op 07-04-2024 16:46 ]

[Villager]

Mich schreef op zondag 7 april 2024 @ 16:42:
Aan de hand van de berichten op de laatste pagina ook eens naar de response tijden gekeken. Als ik met DNS over TLS servers direct uit AGH werk dan is de responsetijd 9-12 msec.

Echter gebruik ik ook opnsense met unbound. Als ik mijn verzoeken via unbound laat lopen kom ik rond de 80 msec uit. Nu moet ik alleen nog uitzoeken of dit nou komt door opnsense of door (verkeerde) unbound instellingen. Ik gebruik in unbound 3 DNS over TLS servers. Als ik deze uitzet maakt het niet veel verschil in tijd.

Misschien maar eens een unbound in een docker draaien om te zien wat dat doet met de tijden.

Hier zo'n beetje hetzelfde hoor. Ook AGH met Unbound en DOT. Zat ook op 70ms. Had lokale DNS Requests naar o.a. mn printer die vaak rond de 10 sec. duurde. Nu dat opgelost is door in de host file van m'n PC de hostname te verwijzen naar het ip adres van de printer zit ik op 30ms.

[ Voor 5% gewijzigd door Villager op 07-04-2024 18:51 ]

[alex3305]

@Mich De responsetijd van mijn primaire AdGuard Home installatie is de afgelopen week rond de 0.8ms en mijn secundaire installatie rond de 1.7ms. Allebei voor mij dik in orde omdat AdGuard Home enorm efficient van z'n cache gebruik maakt. De gemiddelde Unbound responsetijden liggen tussen de 26ms en 80ms. Dat lijkt traag, maar wordt niet zo bijster vaak aangesproken.

De afgelopen week zijn er zo'n ~270.000 DNS requests binnengekomen, waarvan er ~46.000 zijn geblokkeerd en maar ~9000 naar een upstream server zijn gegaan. Dus uiteindelijk merk ik vrij weinig van het feit dat de Unbound DNS server niet bijster snel is.

Overigens heb ik onlangs een TTL ingesteld op lokale domeinen in de dnsmasq van mijn ASUS router door deze configuratieregel toe te voegen:

# Set local TTL to 30 minutes
local-ttl=300

Het voordeel is dan dat AdGuard Home deze requests vanuit cache kan serveren in plaats van dat deze elke keer een DNS request doet naar de router. Het nadeel is uiteraard dat er een cache is mocht ik wijzigingen maken. Maar dat doe ik eigenlijk bijna nooit .

[zunrob]

alex3305 schreef op zondag 7 april 2024 @ 21:54:
@Mich De responsetijd van mijn primaire AdGuard Home installatie is de afgelopen week rond de 0.8ms en mijn secundaire installatie rond de 1.7ms. Allebei voor mij dik in orde omdat AdGuard Home enorm efficient van z'n cache gebruik maakt. De gemiddelde Unbound responsetijden liggen tussen de 26ms en 80ms. Dat lijkt traag, maar wordt niet zo bijster vaak aangesproken.

De afgelopen week zijn er zo'n ~270.000 DNS requests binnengekomen, waarvan er ~46.000 zijn geblokkeerd en maar ~9000 naar een upstream server zijn gegaan. Dus uiteindelijk merk ik vrij weinig van het feit dat de Unbound DNS server niet bijster snel is.

Overigens heb ik onlangs een TTL ingesteld op lokale domeinen in de dnsmasq van mijn ASUS router door deze configuratieregel toe te voegen:

# Set local TTL to 30 minutes
local-ttl=300

Het voordeel is dan dat AdGuard Home deze requests vanuit cache kan serveren in plaats van dat deze elke keer een DNS request doet naar de router. Het nadeel is uiteraard dat er een cache is mocht ik wijzigingen maken. Maar dat doe ik eigenlijk bijna nooit .

Heb jij dus in AGH optimistic caching aanstaan?

[alex3305]

zunrob schreef op zondag 7 april 2024 @ 22:32:
[...]


Heb jij dus in AGH optimistic caching aanstaan?

Ja. Ik zal het ook eens kijken zonder die optie.

[lolgast]

Ik merk dat Videoland altijd stuk gaat als caching aanstaat.. Jullie daar allemaal geen last van?

[Jorco]

Sinds kort (ik vermoed sinds dit weekend) krijgt 1 tablet geen verbinding met het internet wanneer Adguard aan staat.

Ter verduidelijking is de opzet als volgt:
Ziggo modem (bridge modus) --> Deco X50 --> Netgear GS105Ev2 --> NUC met Proxmox en hierop Adguard geïnstalleerd. Alles bekabeld aangesloten.

Adguard Home met de volgende lijsten:
AdGuard DNS filter
HaGeZi's Pro++

Verder niets bijzonders ingesteld.

Deco verwijst bij DHCP server instellingen naar AdGuard DNS.

Alle andere apparaten hebben gewoon verbinding maar de Xiaomi Pad 6 Pro weigert opeens.

Om het nog gekker te maken: Indien ik Adguard voor 1 minuut uitzet en in de tussentijd opnieuw verbind met Wi-Fi dan blijft de verbinding in stand, ook wanneer Adguard weer inschakelt. Zodra de Xiaomi opnieuw verbinding moet maken dan lukt het weer niet.

Laat ik de Xiaomi-tablet met andere netwerken verbinden is er ook geen probleem.

Heeft iemand een idee welke instelling/regel in Adguard hier dwarsligt?

Edit: Het zit in de lijst van HaGeZi. Mocht iemand een soortgelijk issue tegenkomen dan de volgende uitzondering even toevoegen aan de aangepaste filter regels:
@@||connect.rom.miui.com^

[ Voor 10% gewijzigd door Jorco op 15-04-2024 23:05 ]

[Villager]

Jorco schreef op maandag 15 april 2024 @ 20:54:
Sinds kort (ik vermoed sinds dit weekend) krijgt 1 tablet geen verbinding met het internet wanneer Adguard aan staat.

Ter verduidelijking is de opzet als volgt:
Ziggo modem (bridge modus) --> Deco X50 --> Netgear GS105Ev2 --> NUC met Proxmox en hierop Adguard geïnstalleerd. Alles bekabeld aangesloten.

Adguard Home met de volgende lijsten:
AdGuard DNS filter
HaGeZi's Pro++

Verder niets bijzonders ingesteld.

Deco verwijst bij DHCP server instellingen naar AdGuard DNS.

Alle andere apparaten hebben gewoon verbinding maar de Xiaomi Pad 6 Pro weigert opeens.

Om het nog gekker te maken: Indien ik Adguard voor 1 minuut uitzet en in de tussentijd opnieuw verbind met Wi-Fi dan blijft de verbinding in stand, ook wanneer Adguard weer inschakelt. Zodra de Xiaomi opnieuw verbinding moet maken dan lukt het weer niet.

Laat ik de Xiaomi-tablet met andere netwerken verbinden is er ook geen probleem.

Heeft iemand een idee welke instelling/regel in Adguard hier dwarsligt?

Edit: Het zit in de lijst van HaGeZi. Mocht iemand een soortgelijk issue tegenkomen dan de volgende uitzondering even toevoegen aan de aangepaste filter regels:
@@||connect.rom.miui.com^

Heb zelf ook een MiPad 5 en heb deze problemen niet ervaren. Gebruik de HaGeZi lijst ook niet. Op deze pagina is er trouwens nog meer over te lezen, ook t.a.v. updates.

Dank voor je edit met de oplossing!

[Glassertje]

alex3305 schreef op vrijdag 1 december 2023 @ 15:08:
@ahbart @Glassertje Ik ben een tijdje terug van Cloudflare's resolvers afgestapt. Ik werd er knettergek van dat archive.is (en alternatieve namen) 1.1.1.1 gebruikers blokkeert.

Toevallig dacht ik net aan deze post van je en kan nu wel via cloudflare https://archive.is/ bereiken.

Archive had cloudflare geblokkeerd, omdat cloudflare weigerde om EDNS subnet mee te sturen. Hier het hele verhaal, mocht je er interesse in hebben.

[Hmmbob]

Ik kwam met deze DNS server regels eigenlijk geen problemen meer tegen:

code:

[/archive.is/archive.today/]tls://dns.quad9.net

[alex3305]

@Glassertje Bedankt. Ik gebruik inmiddels alleen nog Unbound als upstream server(s).

---

@zunrob Zonder optimistic caching verdubbelde mijn response tijden. Nog steeds zo rond de 3ms, dus eigenlijk niets te klagen. Maar heb het toch maar weer aangezet. Het is wat mij betreft ook een van de sterkte punten van Adguard Home.

[NickC]

Ik heb nu Adguard draaien en daarnaast heb ik ook nog Wireguard zodat ik met m'n thuisnetwerk kan verbinden. Nu zou ik graag ook willen dat via Wireguard ook mijn Adguard werkt.

Online word ik er zelf niet veel wijzer van. Is er hier iemand die dit toevallig heefd draaien op Homeassistant?

[Villager]

Ik heb een aparte Debian container op Proxmox alleen voor Wireguard. Heb er PiVPN op draaien. Maak er verbinding mee met al mn devices en ga zo standaard ook naar Internet. Op mn mobiel heb ik de WGtunnel App draaien waarmee ik automatisch, bij verlaten van mn thuis wifi, een WG verbinding opzet.

[EverLast2002]

NickC schreef op maandag 29 april 2024 @ 21:56:
Ik heb nu Adguard draaien en daarnaast heb ik ook nog Wireguard zodat ik met m'n thuisnetwerk kan verbinden. Nu zou ik graag ook willen dat via Wireguard ook mijn Adguard werkt.

Online word ik er zelf niet veel wijzer van. Is er hier iemand die dit toevallig heefd draaien op Homeassistant?

In de config file van WireGuard zet je het ip adres van je AdGuard server als DNS.
Ik draai PiVPN en daar heet die config file "/etc/pivpn/wireguard/setupVars.conf"
Wellicht in een "gewone" WireGuard server heet en staat ie ergens in /etc/wireguard/

[alex3305]

Villager schreef op dinsdag 30 april 2024 @ 06:36:
Op mn mobiel heb ik de WGtunnel App draaien waarmee ik automatisch, bij verlaten van mn thuis wifi, een WG verbinding opzet.

Die app heb ik vorige week uitgeprobeerd, maar crashte elke keer op mijn S21+ wanneer ik een tunnel opzette. Heel jammer. Vooral omdat dit op iOS wel standaard in Wireguard zit.

[EverLast2002]

alex3305 schreef op dinsdag 30 april 2024 @ 12:57:
[...]
Vooral omdat dit op iOS wel standaard in Wireguard zit.

die zin snap ik niet helemaal....

[alex3305]

EverLast2002 schreef op dinsdag 30 april 2024 @ 15:40:
[...]

die zin snap ik niet helemaal....

Op iOS heb je Wireguard On Demand in de officiële client zitten. Dat mist op Android. Ik vind dat enorm jammer. Ik heb ook al geprobeerd om vanuit Home Assistant een Wireguard tunnel op te starten, maar ook dat gaat niet omdat de Android Home Assistant Companion App niet de com.wireguard.android.permission.CONTROL_TUNNELS permissie heeft.

Voor Adguard Home heb ik dit opgelost door DNS-over-TLS te gebruiken in Android. Dan heb ik geen tunnel nodig voor mijn eigen DNS server. Maar dat heeft ook verschillende haken en ogen .

[NickC]

EverLast2002 schreef op dinsdag 30 april 2024 @ 12:55:
[...]


In de config file van WireGuard zet je het ip adres van je AdGuard server als DNS.
Ik draai PiVPN en daar heet die config file "/etc/pivpn/wireguard/setupVars.conf"
Wellicht in een "gewone" WireGuard server heet en staat ie ergens in /etc/wireguard/

Thnx, heb het gewoon in de configuratie file aangepast waar je OA. DuckDNS toevoegt.

[Robbie T]

Hallo,
Ik heb adguard geïnstalleerd op mijn Unraid instantie en dit werkt prima voor het grootste deel van de tijd. Ik gebruik 3 blocklists;
- HaGeZi's Pro-bloklijst
- HaGeZi's Threat Intelligence Feeds
- OISD-bloklijst groot
Ik heb ook één allowlist;
- HaGeZi's Allowlist Verwijzing

Ik heb echter problemen met sommige domeinen. Dit gaat over tradetracker en google adservices.

Wanneer ik klik op een link op Google Shopping link krijg ik een "this page can't be found/address invalid error". Het hoofdgedeelte van de url is: https://ad.doubleclick.net/searchads/link/click?

Ook bij Pepper ervaar ik problemen. Als ik op een uitgaande link klik, krijg ik ook een foutmelding. Het hoofdgedeelte van de url is: https://tc.tradetracker.net/?

Als ik in het query log van adguard kijk zie ik de query en deze staat als "toegestaan" in de HaGeZi's Allowlist. Dat zou er dus op moeten duiden dat ik de pagina zou kunnen laden.

Als ik Adguard uitschakel kan ik de pagina nog steeds niet laden.
Als ik Adguard actief houd en alle blocklists uitschakel kan ik de pagina nog steeds niet laden.
Wanneer ik een andere DNS server kies bij mijn netwerkkaartinstellingen kan ik de pagina wel laden. Dit geeft dus aan dat het probleem binnen Adguard zit. Ik begrijp echter niet waarom.
Is iemand hier tegenaan gelopen en/of heeft iemand een oplossing?

[EverLast2002]

Robbie T schreef op vrijdag 17 mei 2024 @ 19:49:
Hallo,
Ik heb adguard geïnstalleerd op mijn Unraid instantie en dit werkt prima voor het grootste deel van de tijd. Ik gebruik 3 blocklists;
- HaGeZi's Pro-bloklijst
- HaGeZi's Threat Intelligence Feeds
- OISD-bloklijst groot
Ik heb ook één allowlist;
- HaGeZi's Allowlist Verwijzing

Ik heb echter problemen met sommige domeinen. Dit gaat over tradetracker en google adservices.

Wanneer ik klik op een link op Google Shopping link krijg ik een "this page can't be found/address invalid error". Het hoofdgedeelte van de url is: https://ad.doubleclick.net/searchads/link/click?

Ook bij Pepper ervaar ik problemen. Als ik op een uitgaande link klik, krijg ik ook een foutmelding. Het hoofdgedeelte van de url is: https://tc.tradetracker.net/?

Als ik in het query log van adguard kijk zie ik de query en deze staat als "toegestaan" in de HaGeZi's Allowlist. Dat zou er dus op moeten duiden dat ik de pagina zou kunnen laden.

Als ik Adguard uitschakel kan ik de pagina nog steeds niet laden.
Als ik Adguard actief houd en alle blocklists uitschakel kan ik de pagina nog steeds niet laden.
Wanneer ik een andere DNS server kies bij mijn netwerkkaartinstellingen kan ik de pagina wel laden. Dit geeft dus aan dat het probleem binnen Adguard zit. Ik begrijp echter niet waarom.
Is iemand hier tegenaan gelopen en/of heeft iemand een oplossing?

Kan het zijn dat de Blocklist een Allowlist overruled?
Als ik het goed herinner kun je ook domeinen/URLs handmatig toevoegen aan een Whitelist.

En wanneer je een andere DNS server invult dan lijkt het mij logisch dat je de website wel kunt bereiken, want je omzeilt dan AdGuard.

[Robbie T]

EverLast2002 schreef op vrijdag 17 mei 2024 @ 20:53:
[...]


Kan het zijn dat de Blocklist een Allowlist overruled?
Als ik het goed herinner kun je ook domeinen/URLs handmatig toevoegen aan een Whitelist.

En wanneer je een andere DNS server invult dan lijkt het mij logisch dat je de website wel kunt bereiken, want je omzeilt dan AdGuard.

Ik zou mijn post net editen maar ik heb het gevonden (met hulp van reddit). Ik had Upstream DNS server geconfigureerd welke ook standaard blokkades toepassen. Zojuist unfiltered DNS toegepast en daarmee is het probleem opgelost.

[Glassertje]

Update AdGuard Home v0.107.50

[qwasd]

Wat is jullie ervaring met optimistic caching? hebben jullie dat aan staan en zo ja waarom?

[alex3305]

qwasd schreef op zaterdag 1 juni 2024 @ 10:49:
Wat is jullie ervaring met optimistic caching? hebben jullie dat aan staan en zo ja waarom?

Als ik het optimistic caching uitzette verdubbelde mijn gemiddelde response tijd van rond de 1.5ms naar 3ms. Ik heb geen negatieve ervaringen met optimistic caching, maar daar denken anderen hier anders over.

[qwasd]

Een andere vraag. Ik draai mijn Adguard Home op een Synology NAS als docker container en ik heb op mijn UDM Pro (router) voor 1 netwerk de Adguard Home instance als dns server (ip adres) opgegeven. Ik maak namelijk niet voor alle netwerken/vlans gebruik van Adguard Home. De andere netwerken/vlans gebruiken weer de DNS server (Cloudflare 1.1.1.1/1.0.0.1) van de wan interface op de UDM Pro. Dit werkt al jaren prima maar ik ben toch benieuwd of mijn Adguard Home performance wel goed is vergeleken met jullie situatie en of ik de instellingen wel juist heb staan.

DNS Settings

code:

Parallel requests: Ingeschakeld
Use private dns resolvers: Ingeschakeld
Enable reserve resolving of client ip addresses: Ingeschakeld

Rate limit: 20
Subnet prefix length for IPv4 addresses: 24
Subnet prefix length for IPv6 addresses: 56
Enable eDNS client subnet: Uitgeschakeld
Enable DNSSEC: Ingeschakeld
Disable resolving of ipv6 addresses: Uitgeschakeld
Blocking mode: Default

Cache size: 4194304
Override minimum ttl: -
Override maximum ttl: -
Optimistic caching: Uitgeschakeld

DNS Blocklists

code:

AdGuard DNS filter
AdAway Default Blocklist
OISD

Upstream DNS servers

code:

tls://1dot1dot1dot1.cloudflare-dns.com
https://dns.cloudflare.com/dns-query
tls://dns.quad9.net
https://dns.quad9.net/dns-query

Bootstrap DNS servers:

code:

1.1.1.1
1.0.0.1
2606:4700:4700::1111
2606:4700:4700::1001

Nu is mijn Average processing time onder General statistics 12 ms

Average upstream response time over de afgelopen 30 dagen:

code:

https://dns.cloudflare.com:443/dns-query
19 ms
tls://1dot1dot1dot1.cloudflare-dns.com:853
15 ms
tls://dns.quad9.net:853
14 ms
https://dns.quad9.net:443/dns-query
14 ms

* Ik maak geen gebruik van Unbound maar misschien is dit iets om naar te kijken

[ Voor 5% gewijzigd door qwasd op 01-06-2024 11:47 ]

[alex3305]

@qwasd Op een NAS kan dat vrij redelijk zijn. Op mijn NAS, die ik als secundaire DNS had geconfigureerd, had ik een average response time van rond de 15ms. Dat was met een Intel J1800, dus een vrij langzame processor. Met mijn J4105 daarentegen haalde ik al 4ms.

Ik denk dat jouw grootste besparing zit 'em in het niet gebruik van TLS/HTTPS en het aanzetten van optimistic caching. De rest van de instellingen zijn prima.

[Game-Freak]

Update AdGuard Home v0.107.51

A small bugfix and security release. We are working on new features in future releases.

Full changelog

See also the v0.107.51 GitHub milestone.

Security

Go version has been updated to prevent the possibility of exploiting the Go vulnerabilities fixed in Go 1.22.4.

Changed

The HTTP server's write timeout has been increased from 1 minute to 5 minutes to match the one used by AdGuard Home's HTTP client to fetch filtering-list data (#7041).

[RCBL]

Kan iemand mij even updaten. Ik zie regelmatig updates Adquard Home op de FP staan. Zoals nu ook
v0.1074.51. Heb hier ook Adguard op de desktop draaien echter die geeft als versie: 7.17.1 (4709)

??!!

[eric.1]

RCBL schreef op vrijdag 7 juni 2024 @ 12:35:
Kan iemand mij even updaten. Ik zie regelmatig updates Adquard Home op de FP staan. Zoals nu ook
v0.1074.51. Heb hier ook Adguard op de desktop draaien echter die geeft als versie: 7.17.1 (4709)

??!!

Dat zijn gewoon twee verschillende producten.

AdGuard Home (v0.107.51) is een service welke je zelf moet draaien op een server (vergelijkbaar met PiHole). Dit werkt op netwerk-niveau, als in je moet de DNS-instellingen in je netwerk dusdanig aanpassen dat ieder gewenst device de name-resolving via Adguard Home laat lopen.
https://adguard.com/en/adguard-home/overview.html
https://github.com/AdguardTeam/AdguardHome

AdGuard AdBlocker (v7.17, 14) (of AdGuard for Windows) is een device-specifieke AdBlocker, gewoon een ander product met een iets andere doel/doelgroep.
https://adguard.com/en/adguard-windows/overview.html

[Villager]

Bij mij staat er v0.107.51

[Glassertje]

Keek weer ens niet goed, voor ik reageer. Excuses.

[ Voor 93% gewijzigd door Glassertje op 07-06-2024 13:31 ]

[RCBL]

eric.1 schreef op vrijdag 7 juni 2024 @ 12:43:
[...]

Dat zijn gewoon twee verschillende producten.

AdGuard Home (v0.107.51) is een service welke je zelf moet draaien op een server (vergelijkbaar met PiHole). Dit werkt op netwerk-niveau, als in je moet de DNS-instellingen in je netwerk dusdanig aanpassen dat ieder gewenst device de name-resolving via Adguard Home laat lopen.
https://adguard.com/en/adguard-home/overview.html
https://github.com/AdguardTeam/AdguardHome

AdGuard AdBlocker (v7.17, 14) (of AdGuard for Windows) is een device-specifieke AdBlocker, gewoon een ander product met een iets andere doel/doelgroep.
https://adguard.com/en/adguard-windows/overview.html

Dank voor de heldere uitleg..Bern weer helemaal bij...

[Giku]

Heb sinds gister Adguard Home draaien. Alles werkt overal perfect, alleen mijn NLZiet App op de Nvidia Shield weigert te werken, wat ik ook probeer.

Op mijn telefoon en PC werkt NLZiet wel.
Op de Shield krijg ik wel een melding dat Ethernet niet verbonden is op de plekken waar ik reclame verwacht - in de instellingen staat het wel als verbonden. Netflix en andere services doen het prima op de Shield, het gaat dus alleen mis bij de NLZiet app.

Iemand enig idee waar het misgaat? Wist even niet zeker welk topic ik het ook zou moeten vragen dus probeer hier eerst.

[PatRamon]

Giku schreef op donderdag 13 juni 2024 @ 17:20:
Heb sinds gister Adguard Home draaien. Alles werkt overal perfect, alleen mijn NLZiet App op de Nvidia Shield weigert te werken, wat ik ook probeer.

Op mijn telefoon en PC werkt NLZiet wel.
Op de Shield krijg ik wel een melding dat Ethernet niet verbonden is op de plekken waar ik reclame verwacht - in de instellingen staat het wel als verbonden. Netflix en andere services doen het prima op de Shield, het gaat dus alleen mis bij de NLZiet app.

Iemand enig idee waar het misgaat? Wist even niet zeker welk topic ik het ook zou moeten vragen dus probeer hier eerst.

1. Al geprobeerd om even tijdelijk Adguard uit te zetten? en wel resultaat voordat je verder gaat verdiepen.

2. Adguard via je interface benaderen en alle history wissen. (Ofwel alles weer op 0)
*Even geen andere dingen doen in huis via internet.

Vervolgens NLZiet opstarten via je shield en de "beruchte" service white listen die mogelijk geblockt staat.

Dit kun je ook uiteraard doen voor andere diensten die ineens niet goed werken met Adguard aan.

[Giku]

Zul je altijd, volgens mij is het een vlan probleem Bij het uitzetten deed alles het uiteraard. Toch maar even zelf klussen weer.

[alex3305]

@Giku Je kunt ook proberen Optimistic Caching uit te zetten. Sommige services willen daar nog weleens moeite mee hebben.

[Kitser]

Ik heb Adguard Home als addon in Home Assistant. Samen met OISD Blocklist Big uit TS.
Dat werkt prima.
Alleen in de Marktplaats app heb ik nog steeds adds. Weet iemand hoe ik deze kan blokkeren?

[TheCeet]

Kitser schreef op maandag 17 juni 2024 @ 15:18:
Ik heb Adguard Home als addon in Home Assistant. Samen met OISD Blocklist Big uit TS.
Dat werkt prima.
Alleen in de Marktplaats app heb ik nog steeds adds. Weet iemand hoe ik deze kan blokkeren?

Lokale cache toevallig? App eens deleten en opnieuw installeren?
Indien je ads ziet, query log is the place 2 be om als eerste domains te controleren.

Meteen bij vermelden.
Indien Android toestel: die maken gebruik van hardcoded DNS. Dus bepaalde zaken worden geskipped door ingestelde DNS en gaan rechtstreeks naar Google DNS.
Al het DNS forceren naar IP van AdGuard Home is dus de oplossing.
Of Google DNS blokkeren op firewall niveau.

[alex3305]

@TheCeet Ik gebruik Marktplaats nauwelijks, maar het kunnen ook de 'gesponsorde advertenties' zijn waar @Kitser het over heeft... Die kun je niet (zomaar) weghalen

[ Voor 11% gewijzigd door alex3305 op 19-06-2024 20:40 ]

[Kitser]

TheCeet schreef op dinsdag 18 juni 2024 @ 19:59:
[...]

Lokale cache toevallig? App eens deleten en opnieuw installeren?
Indien je ads ziet, query log is the place 2 be om als eerste domains te controleren.

Meteen bij vermelden.
Indien Android toestel: die maken gebruik van hardcoded DNS. Dus bepaalde zaken worden geskipped door ingestelde DNS en gaan rechtstreeks naar Google DNS.
Al het DNS forceren naar IP van AdGuard Home is dus de oplossing.
Of Google DNS blokkeren op firewall niveau.

Het gaat inderdaad om Android.
Ik had het voorheen wel op m'n Edgerouter ingesteld dat 53 werd geredirect naar m'n Home Assistant Server (met Adguard Home Addon).
Moet even zoeken waar ik dit in m'n UniFi USG kan doen.

alex3305 schreef op woensdag 19 juni 2024 @ 20:40:
@TheCeet Ik gebruik Marktplaats nauwelijks, maar het kunnen ook de 'gesponsorde advertenties' zijn waar @Kitser het over heeft... Die kun je niet (zomaar) weghalen

Die ingebouwde advertenties zie ik indd ook. Maar ik ben me ervan bewust dat die niet weg kunnen.
Maar er staan ook nog echte reclames tussen.

[ Voor 21% gewijzigd door Kitser op 19-06-2024 23:04 ]

[Satom]

Vanwege de DoH ben ik bezig om de overstap van Pi-Hole naar AdGuard te maken, het enige waar ik niet echt kom en wellicht zie ik het over het hoofd: in Pi-Hole heb ik de default groep op non-blocking gezet, dus alle clients op het netwerk zullen ads etc. krijgen, tenzij ik de client toevoeg aan een “blocking” groep. Reden hiervoor is dat vrouwlief het ontzettend vervelend vind dat de shoppingsites, Google search ads etc geblokkeerd zijn.

Dus standaard zullen er geen filters worden toegepast op clients.

Iemand enig idee hoe ik dit in AdGuard voor elkaar kan krijgen?

[ Voor 6% gewijzigd door Satom op 03-07-2024 17:33 ]

[lolgast]

@Satom
Ik zou hem omdraaien:
Alle devices in de normale configuratie en het device van je vrouw excluden. Dat kan door het apparaat als ‘client’ te defineren via bijvoorbeeld het IP-adres en vervolgens in te stellen dat er niets geblokkeerd moet worden.
Een andere optie is zoeken naar blocklists die o.a. Google Search niet stuk maken zoals bijvoorbeeld de OISD lijst

[Glassertje]

Update AdGuard Home v0.107.52

[bagje]

Hi mede adguard gebruikers! Ik ben aan 't stoeien met de whitelist om ervoor te zorgen dat op z'n minst Videoland en netflix goed blijven werken. Ik heb enkele sites al in gedachte, maar dacht dat er meer waren. Ook blijft voornamelijk videoland nog weleens vasthangen.
Heeft er iemand een volledig lijstje voor me?

cdns.gigya.com
cdns.eu1.gigya.com
accounts.eu1.gigya.com
gscounters.eu1.gigya.com

[ Voor 10% gewijzigd door bagje op 05-07-2024 11:52 ]

[Hmmbob]

Welke blocklist gebruik je dan? Want hier werken die twee diensten prima icm AdGuard en de Big OISD lijst

[ Voor 11% gewijzigd door Hmmbob op 05-07-2024 13:06 ]

[bagje]

Hmmbob schreef op vrijdag 5 juli 2024 @ 13:05:
Welke blocklist gebruik je dan? Want hier werken die twee diensten prima icm AdGuard en de Big OISD lijst

O natuurlijk. ik ga gebruik deze: https://github.com/ppfeuf...master/blocklist?raw=true
en alleen die.
aangezien daar alle filters in verwerkt zitten en wordt vanzelf bijgewerkt (dagelijks)

[Hmmbob]

Misschien de moeite waard om eens alleen OISD te proberen. Terugswitchen kan altijd.

[bagje]

hm is wel lastig om te bepalen welke list nu 't beste is/meest uitgebreide en dan ook gericht op NL. de OISD is nieuw voor mij. hoe ben je daarop gekomen als ik vragen mag?

edit: ik zie dat de big list ook in die van mij zit: https://github.com/ppfeuf...h-lists-are-combined-here

[ Voor 28% gewijzigd door bagje op 05-07-2024 13:28 ]

[Hmmbob]

bagje schreef op vrijdag 5 juli 2024 @ 13:24:
hm is wel lastig om te bepalen welke list nu 't beste is/meest uitgebreide en dan ook gericht op NL. de OISD is nieuw voor mij. hoe ben je daarop gekomen als ik vragen mag?

De startpost.

edit: ik zie dat de big list ook in die van mij zit: https://github.com/ppfeuf...h-lists-are-combined-here

Ik ben geen fan van al die gecombineerde lijsten: veel te veel kans dat er iets fout gaat.

[Robbie T]

Ik gebruik de volgende lijsten;
https://adguardteam.githu...stry/assets/filter_48.txt
https://adguardteam.githu...stry/assets/filter_44.txt
https://adguardteam.githu...stry/assets/filter_27.txt

En de volgende whitelist;
https://adguardteam.githu...stry/assets/filter_45.txt

Ik ervaar geen problemen tijdens het browsen en gemiddeld wordt 36% geblokt.

[alex3305]

Hmmbob schreef op vrijdag 5 juli 2024 @ 13:38:
[...]

Ik ben geen fan van al die gecombineerde lijsten: veel te veel kans dat er iets fout gaat.

Idem hier. In het begin een paar keer geprobeerd, maar de hoeveelheid false positives was veel te groot. Ik gebruik nu AdGuard en OISD en dat gaat prima.

@bagje Deze lijsten, waaronder OISD, zitten overigens ook in de interface / wizard in AdGuard Home zelf.

[Glassertje]

Hmmbob schreef op vrijdag 5 juli 2024 @ 13:38:
[...]
De startpost.

[...]

Ik ben geen fan van al die gecombineerde lijsten: veel te veel kans dat er iets fout gaat.

OISD is anders ook een verzameling van verschillende lijsten.

[Pierre]

Ik heb ook AH draaien op een RaspBerry, echter ik krijg het niet voor elkaar om de filmpjes die via NU.nl geserveerd worden af te spelen, hij blockt ze op een of andere manier.

Als ik deze blokkeerlijst uitschakel dan werken die filmpje wel:

https://raw.githubusercon...ists/master/blocklist.txt

Bij inschakelen doen ze het weer niet

Dit heb bij de aangepaste filter regels gezet maar dit doet niet wat ik wil, iemand hier die weet wat ik moet doen.

@@||nu.nl^
@@||cmp.nu.nl^
@@||media.nu.nl^
@@||dpg.pexi.nl^
@@||myprivacy-static.dpgmedia.net^
@@||metrics.nu.nl^
@@||temptation.nu.nl^
@@||graph.nu.nl^

[ Voor 3% gewijzigd door Pierre op 06-07-2024 11:55 ]