[AdGuard Home] Ervaringen & discussie

[lolgast]

@Ragnar9999 Ik zit op 130 blocked volgens die site, dus voor een deel moet het toch ook aan je blocklists liggen denk ik. Ik gebruik eigenlijk alleen de OISD lijst

[Ragnar9999]

Die heb ik er ook bij zitten (OISD)
en bij check filtering onderaan de custom filtering rules worden er hosts geblocked die volgens deze site niet geblocked worden

[Ragnar9999]

lolgast schreef op dinsdag 26 december 2023 @ 11:10:
@Ragnar9999 Ik zit op 130 blocked volgens die site, dus voor een deel moet het toch ook aan je blocklists liggen denk ik. Ik gebruik eigenlijk alleen de OISD lijst

Of je zorgt ervoor dat je niet via DHCP als alternative DNS ook nog een tweede DNS server op de geteste client krijgt
dank je wel

[sennevb]

lenwar schreef op zaterdag 16 mei 2020 @ 17:24:
Zoals beloofd. Zo heb ik Adguard Home op m'n Ubiquiti USG3 geïnstalleerd:


log in als admin op je USG3

wordt root:

code:

# sudo su - root

Maak een directory aan waar je al je binaries in zet in de /config tree. Deze tree wordt bij een upgrade niet overschreven:

code:

# mkdir /config/sbin

Download de mips versie van de AdguardHome release van https://github.com/AdguardTeam/AdGuardHome/releases/ naar /config/sbin
(op het moment van schrijven https://github.com/Adguar...ardHome_linux_mips.tar.gz )
De Unifi routers draaien op een mips64 CPU, dus als die mettertijd gecompileerd wordt kan dat iets sneller/efficienter functioneren.

code:

# curl -L https://github.com/AdguardTeam/AdGuardHome/releases/download/v0.102.0/AdGuardHome_linux_mips.tar.gz --output AdGuardHome_linux_mips.tar.gz

pak de tar-bal uit:

code:

# tar -xxf AdGuardHome_linux_mips.tar.gz

code:

# cd AdGuardHome

Installeer de init scripts:

code:

# ./AdGuardHome -s install

start AdGuardHome op:

code:

# /etc/init.d/AdGuardHome start

Klaar als root-user

code:

# exit

ga de configuratie-modus in:

code:

$ configure

Stel de ingebouwde dnsmasq in om op (bijvoorbeeld) poort 5354 te laten luisteren, en je dnsmasq ook laten doorsturen naar zichzelf (om loops te voorkomen)

code:

# set service dns forwarding options port=5354

code:

# set service dns forwarding options server=127.0.0.1#5354

code:

# commit

code:

# save

Verlaat de ssh-sessie

code:

exit

code:

exit

Vanaf hier ga je het standaard installatietraject van AdGuard Home in. (dus ga naar http://<router-ip>:3000/)

Indien je aanpassingen ook in je controller wil opslaan kan/moet je dit ook nog zetten in je config.gateway.json
Let op, onderstaande is slechts een voorbeeld. Jouw situatie kan afwijken. Kijk in de /etc/dnsmasq.conf hoe hij er bij jou uit ziet!!

code:

{
        "service": {
                "dns": {
                        "forwarding": {
                                "cache-size": "1024",
                                "except-interface": [
                                        "eth0"
                                ],
                                "options": [
                                        "ptr-record=XXXXXXXXX",
                                        "host-record=XXXXXXXX",
                                        "domain-needed",
                                        "bogus-priv",
                                        "stop-dns-rebind",
                                        "server=127.0.0.1#5354",
                                        "trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5",
                                        "trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D",
                                        "dnssec",
                                        "dnssec-check-unsigned",
                                        "dnssec-no-timecheck",
                                        "port=5354"
                                ]
                        }
                }
    }
}

Extraatje:
Indien je wil forceren dat alle apparaten altijd over je AdGuard Home heen gaan (Chromecasts gaan standaard naar de DNS-servers van Google), kan je devolgende NAT-regels in je config.gateway.json zetten:

Onderstaand voorbeeld is voor twee vlans. De regels aanpassen aan jouw omgeving:

code:

{
    "service": {
        "nat": {
            "rule": {
                "1": {
                    "description": "DNS omleiden naar router - Basisnetwerk",
                    "destination": {
                        "port": "53",
                        "address": "!192.168.1.1"
                    },
                    "inside-address": {
                        "address": "192.168.25.1",
                        "port": "53"
                    },
                    "inbound-interface": "eth1",
                    "log": "disable",
                    "protocol": "tcp_udp",
                    "type": "destination"
                },
                "2": {
                    "description": "DNS omleiden naar router - VLAN 3",
                    "destination": {
                        "port": "53",
                        "address": "!192.168.3.1"
                    },
                    "inside-address": {
                        "address": "192.168.25.1",
                        "port": "53"
                    },
                    "inbound-interface": "eth1.3",
                    "log": "disable",
                    "protocol": "tcp_udp",
                    "type": "destination"
                },
                "5001": {
                    "description": "DNS-antwoord van omleiding - Basisnetwerk",
                    "destination": {
                        "address": "192.168.1.1",
                        "port": "53"
                    },
                    "outbound-interface": "eth1",
                    "protocol": "tcp_udp",
                    "type": "masquerade"
                },
                "5002": {
                    "description": "DNS-antwoord van omleiding - VLAN 1",
                    "destination": {
                        "address": "192.168.3.1",
                        "port": "53"
                    },
                    "outbound-interface": "eth1.3",
                    "protocol": "tcp_udp",
                    "type": "masquerade"
                }
            }
        }
    }
}

@lenwar ik heb middels deze instructies adguard al op mijn usg pro geinstalleerd.
Als ik naar de installatie ga in de browser, moet ik hier dan poort 5354 gebruiken, want de standaard dns poort is al in gebruik natuurlijk?

[sennevb]

Ik heb Adguard Home op mijn synology draaien (ip 192.168.0.220), omdat ik het rechtsreeks op de USG nog niet werkende krijg.
Als ik de LAN settings aanpas in mijn unifi controller loopt het wifi verkeer niet via AGH, wat doe ik fout?

Als ik de WAN settings aanpas werkt het wel, maar dan is de gebruiker steeds 192.168.0.1 (de usg pro) en ik wil dit natuurlijk per client zien.

Iemand enig idee? Reboot van AP's deed de truc ;-)

[ Voor 6% gewijzigd door sennevb op 07-01-2024 13:10 ]

[RedPas]

sennevb schreef op zondag 7 januari 2024 @ 12:57:
Ik heb Adguard Home op mijn synology draaien (ip 192.168.0.220), omdat ik het rechtsreeks op de USG nog niet werkende krijg.
Als ik de LAN settings aanpas in mijn unifi controller loopt het wifi verkeer niet via AGH, wat doe ik fout?

Als ik de WAN settings aanpas werkt het wel, maar dan is de gebruiker steeds 192.168.0.1 (de usg pro) en ik wil dit natuurlijk per client zien.

Iemand enig idee? Reboot van AP's deed de truc ;-)


[Afbeelding]

Heb je ook gekeken of je gebruiker het juiste dns ip krijgt?
In Unifi je dns ip veranderen en dan je gebruikers opnieuw laten verbinden

[sennevb]

RedPas schreef op zondag 7 januari 2024 @ 13:23:
[...]

Heb je ook gekeken of je gebruiker het juiste dns ip krijgt?
In Unifi je dns ip veranderen en dan je gebruikers opnieuw laten verbinden

Zoals aangepast in de orginele post deed een AP reboot de truc

[alex3305]

Ik ben een tijdje terug bezig geweest met de Private DNS instelling op Android. Dat zou DNS-over-TLS ondersteunen en DNS-over-HTTPS. Dat laatste is echter gedeeltelijk waar. Nadat ik gister daar nog eens in was gedoken kwam ik erachter dat alleen DNS-over-HTTP3 ondersteund wordt. Omdat mijn huidige reverse proxy (nog) geen HTTP3 praat, werkt dat dus niet. Echter wilde ik toch wat toevallige bezoekers buiten houden.

Wat ik dus gisteren heb gedaan is via mijn reverse proxy (en dus ACME) een Let's Encrypt wildcard domain aangevraagd voor een vierde level domein. Dus voor *.dns.example.com. Deze heb gekoppeld aan AdGuard Home. En hierdoor kan ik namelijk Client ID's toepassen op basis van domeinnaam . In Android heb ik nu dus bij Private DNS alex.dns.example.com, uiteraard met mijn eigen domein, staan. In AdGuard Home heb ik toen bij Settings > Client Settings een Alex client aangemaakt met de identifier alex. En dit komt dan ook netjes naar boven in de Client list:


Echter wilde ik vooral niet geautoriseerde buitenstaanders buiten houden. Ik zag namelijk een aantal requests van Alibaba Cloud uit o.a. Australië en Singapore. Maar dit heb ik nu gedaan met de volgende filter regel:

# Block unknown DNS requests
||*^$client=~192.168.0.0/16|~Alex

Die blokt dus alles behalve lokale requests en mijn eigen requests.

Uiteraard kan ik bij mijn client-id ook nog een soort sleutel meegeven, bijvoorbeeld alex-abcdef1234.dns.example.com om het een en ander nog wat verder af te schermen. Maar vooralsnog ben ik hier al best wel tevreden mee .

[Devrim]

In DNS Settings kan je onder Access Settings afdwingen dat alleen bepaalde IP Ranges en Client IDs toegang hebben tot je Adguard setup, dan hoef je niet perse een filter regel te gebruiken dus ik snap niet helemaal hoe externe scanners dan op je AdGuard Home terechtkomen


Tenzij je in je wildcard cert het hele domein wat je gebruikt hebt vermeld?

[ Voor 30% gewijzigd door Devrim op 15-01-2024 21:53 ]

[teuntjuh]

Is het ook al weer inmiddels mogelijk om youtube reclame hiermee te blocken heb wel al veel geprobeerd. Maar dat lijkt nog niet te kunnen...

Weet iemand iets?

[Hathi]

Blocken van YouTube reclame gaat op DNS niveau niet werken aangezien de reclame's geserveerd worden vanaf dezelfde domeinen als de video's zelf.
Dus daarvoor moet je naar alternatieve adblockers die op device/browser/app niveau werken.

[Ragnar9999]

teuntjuh schreef op vrijdag 19 januari 2024 @ 08:50:
Is het ook al weer inmiddels mogelijk om youtube reclame hiermee te blocken heb wel al veel geprobeerd. Maar dat lijkt nog niet te kunnen...

Weet iemand iets?

YouTube: How to use it with an ad blocker

https://adguard.com/en/bl...t-with-an-ad-blocker.html

[teuntjuh]

Heeft iemand hier een kloppende lijst voor om youtube ads te omzeilen?

[laurens0619]

teuntjuh schreef op vrijdag 19 januari 2024 @ 09:20:
Heeft iemand hier een kloppende lijst voor om youtube ads te omzeilen?

Er bestaat geen lijst
je kan geen youtube ads blokkeren met dns addblocker

[alex3305]

Devrim schreef op maandag 15 januari 2024 @ 21:51:
In DNS Settings kan je onder Access Settings afdwingen dat alleen bepaalde IP Ranges en Client IDs toegang hebben tot je Adguard setup, dan hoef je niet perse een filter regel te gebruiken

Die had ik even gemist. Toegepast in plaats van mijn filter regel. Lijkt in ieder geval functioneel hetzelfde. Bedankt .

[D]us ik snap niet helemaal hoe externe scanners dan op je AdGuard Home terechtkomen

Aangezien poort 853 openstaat, verwacht ik dat hier gewoon een poort scanner langskomt. Dat is niet zo vreemd.

[pielle007]

Heb een vraag, en hoop dat iemand mij op weg kan helpen;

- ik draai thuis AdguardHome op mijn raspberrypi (op mijn ziggo modem staat dhcp uit en regelt de pi verder, verder geen instellingen aangepast op de router)

nu is de wens om ook unbound te gebruiken (ik heb deze handleiding gebruikt, en dat is gelukt.

Unbound draait dus op dezelfde rpi en deze draait (bevestigd)
Binnen AGH heb ik DNSSEC ingeschakeld

Mijn apparaten worden verbonden met lan en wifi na een reboot, echter heb ik geen internet. Wat doe ik niet goed?

[lolgast]

@pielle007 Hebben ze geen internet of kunnen ze geen DNS resolven? Heb je Unbound goed geconfigureerd? Hoe heb je geverifieerd dan Unbound 'draait'?

DNSSEC vanuit AHG naar Unbound heeft volgens mij weinig nut als je DNSSEC in Unbound ook al aan hebt staan. Ik kan me nog een aantal artikelen herinneren waarin stond dat meerdere DNSSEC checks achter elkaar niet bevorderlijk zijn.

Als je in dit topic zoekt naar Unbound kom je meerdere pagina's aan resultaten tegen met o.a. configuraties van meerdere mensen. Wellicht dat dat je op weg kan helpen.

[pielle007]

lolgast schreef op maandag 22 januari 2024 @ 09:28:
@pielle007 Hebben ze geen internet of kunnen ze geen DNS resolven? Heb je Unbound goed geconfigureerd? Hoe heb je geverifieerd dan Unbound 'draait'?

DNSSEC vanuit AHG naar Unbound heeft volgens mij weinig nut als je DNSSEC in Unbound ook al aan hebt staan. Ik kan me nog een aantal artikelen herinneren waarin stond dat meerdere DNSSEC checks achter elkaar niet bevorderlijk zijn.

Als je in dit topic zoekt naar Unbound kom je meerdere pagina's aan resultaten tegen met o.a. configuraties van meerdere mensen. Wellicht dat dat je op weg kan helpen.

Dank voor de reactie, ik ben geen specialist, maar kan wel volgen wat ik moet doen vanuit een handleiding.
Ik heb deze config gebruikt: https://docs.pi-hole.net/guides/dns/unbound/

in dezelfde handleiding staat ook hoe je kunt controleren of Unbound loopt;
Start your local recursive server and test that it's operational:

sudo service unbound restart
dig pi-hole.net @127.0.0.1 -p 5335


DNSSEC uitzetten heb ik ook al eens geprobeerd, zonder succes (dat zou ook niet uit mogen maken, althans ik lees hier dat eea gepatched zou zijn


Wanneer ik Unbound stop en de upstream dns weer aanpas van 127.0.0.1:5335 naar bv google is alles weer functioneel.

Even lastig omdat ik niet weet waar ik t zoeken moet, of welke stappen ik t beste kan volgen om erachter te komen.

[Harmen]

Ben na het Unbound blocklists en Zenarmor avontuur weer terug. Na het aanpassen van de blocklists werkte bepaalde streaming provider niet meer goed. (Videoland) Helaas kan je in Unbound niet goed zien wat er wordt geblocked.

Heb de AdGuard Home plugin weer geactiveerd op m'n Sophos met OPNSense. Heb poort 53 en 853 dicht staan, alles loopt nu via AGH. Chromecasts worden niet gefilterd, videoland werkt weer naar behoren en laat reclames zien.

Heeft er iemand van jullie bestaande url's van streamingdiensten welke gewhitelist kunnen worden?

[pielle007]

Harmen schreef op maandag 22 januari 2024 @ 10:31:
Ben na het Unbound blocklists en Zenarmor avontuur weer terug. Na het aanpassen van de blocklists werkte bepaalde streaming provider niet meer goed. (Videoland) Helaas kan je in Unbound niet goed zien wat er wordt geblocked.

Heb de AdGuard Home plugin weer geactiveerd op m'n Sophos met OPNSense. Heb poort 53 en 853 dicht staan, alles loopt nu via AGH. Chromecasts worden niet gefilterd, videoland werkt weer naar behoren en laat reclames zien.

Heeft er iemand van jullie bestaande url's van streamingdiensten welke gewhitelist kunnen worden?

Heb geen reclame in Videoland (heb binnen de app handmatig de privacy instellingen aangepast, alles nagelopen en afwijzen) en deze blocklists:

AdGuard DNS filter
https://adguardteam.githu...Filter/Filters/filter.txt

AdAway
https://adaway.org/hosts.txt


1Hosts (Pro)
https://o0.pages.dev/Pro/adblock.txt


adguardtracking
https://raw.githubusercon..._17_TrackParam/filter.txt


phisingarmy blocklist
https://phishing.army/download/phishing_army_blocklist.txt


adguardmobilespyware
https://raw.githubusercon.../AdguardMobileSpyware.txt


Malicious URL Blocklist (URLHaus)
https://adguardteam.githu...stry/assets/filter_11.txt


HaGeZi's Threat Intelligence Feeds
https://adguardteam.githu...stry/assets/filter_44.txt


WindowsSpyBlocker - Hosts spy rules
https://adguardteam.githu...stry/assets/filter_23.txt


Dandelion Sprout's Game Console Adblock List
https://adguardteam.githu...istry/assets/filter_6.txt


HaGeZi's Pro++ Blocklist
https://adguardteam.githu...stry/assets/filter_51.txt


Dandelion Sprout's Anti Push Notifications
https://adguardteam.githu...stry/assets/filter_39.txt

xiaomi
https://raw.githubusercon..._block_with_whitelist.lst


Perflyst and Dandelion Sprout's Smart-TV Blocklist
https://adguardteam.githu...istry/assets/filter_7.txt

HageziLGWebos
https://raw.githubusercon...dblock/native.lgwebos.txt


TiktokfingerprtHagezi
https://raw.githubusercon...ative.tiktok.extended.txt


AmazonactivityHagezi
https://raw.githubusercon...adblock/native.amazon.txt


Hagezipersonal
https://raw.githubusercon...main/adblock/personal.txt


HaGeZi's DynDNS Blocklist
https://raw.githubusercon...und/dyndns.blacklist.conf

[Harmen]

@pielle007 Dank, heb nu een 2tal blocklists Adguard standard en Hagezi normal. Doet het nu prima.
Voorheen had ik ook geen reclame bij Videoland, maar liep de stream na 5-10min vast op de chromecast. Herstart van de chromecast was dan nodig.

[pielle007]

Harmen schreef op maandag 22 januari 2024 @ 11:52:
@pielle007 Dank, heb nu een 2tal blocklists Adguard standard en Hagezi normal. Doet het nu prima.
Voorheen had ik ook geen reclame bij Videoland, maar liep de stream na 5-10min vast op de chromecast. Herstart van de chromecast was dan nodig.

np
gebruik ook de chromecast 4k maar herken t vastlopen niet (gelukkig)
(heb op basis van mn blokkeer lijsten niets hoeven te whitelisten)

[Harmen]

pielle007 schreef op maandag 22 januari 2024 @ 12:08:
[...]
np
gebruik ook de chromecast 4k maar herken t vastlopen niet (gelukkig)
(heb op basis van mn blokkeer lijsten niets hoeven te whitelisten)

Google devices gebruiken de standaard googledns 8.8.8.8 heb ik gemerkt, pas als je deze blocked in je netwerk gaan ze via AGH.

[pielle007]

Harmen schreef op maandag 22 januari 2024 @ 12:12:
[...]


Google devices gebruiken de standaard googledns 8.8.8.8 heb ik gemerkt, pas als je deze blocked in je netwerk gaan ze via AGH.

je bedoelt binnen adguard home de aangepaste regel toe te voegen en dan alleen de google dns?

||8.8.8.8^$important
||8.8.4.4^$important

of deze regel?
||www.google.com^$important

[Harmen]

@pielle007 Niet dat, google negeert de opgegeven dns server en gaat vaak zelf via 8.8.8.8 communiceren. Zag eerst helemaal geen query logs van deze apparaten voorbij komen in AGH.

[alex3305]

@Harmen @pielle007 Google DNS wordt (meestal) ook niet gebruikt als je een secundaire DNS opgeeft.

Mijn Google Nest Hub gebruikt bijvoorbeeld ook enorm vaak mijn secundaire Adguard Home instantie. Ongeveer net zo vaak als mijn primaire Adguard.

[ Voor 42% gewijzigd door alex3305 op 22-01-2024 13:03 ]

[alex3305]

Devrim schreef op maandag 15 januari 2024 @ 21:51:
In DNS Settings kan je onder Access Settings afdwingen dat alleen bepaalde IP Ranges en Client IDs toegang hebben tot je Adguard setup, dan hoef je niet perse een filter regel te gebruiken dus ik snap niet helemaal hoe externe scanners dan op je AdGuard Home terechtkomen

Ik had dit dus aangepast.

alex3305 schreef op vrijdag 19 januari 2024 @ 13:50:
Die had ik even gemist. Toegepast in plaats van mijn filter regel. Lijkt in ieder geval functioneel hetzelfde. Bedankt .

Maar het was toch niet helemaal hetzelfde. In de Custom Filtering Rules kon ik dus de door mij toegewezen naam gebruiken, die ik had ingesteld bij Client Settings:

||*^$client=~192.168.0.0/16|~Alex

Maar dat werkt dus niet in DNS Settings > Allowed Clients. Daar moest ik de client ID gebruiken, dus:

192.168.0.0/16
alex

En dan kan ik gebruiken maken van DNS-over-TLS met alex.dns.example.com.

[EverLast2002]

Harmen schreef op maandag 22 januari 2024 @ 12:12:
[...]


Google devices gebruiken de standaard googledns 8.8.8.8 heb ik gemerkt, pas als je deze blocked in je netwerk gaan ze via AGH.

Wanneer je 8.8.8.8 blocked, hoe "gaan ze dan via AGH"?
Dat werkt toch alleen i.c.m een NAT hairpin rule.

[Harmen]

EverLast2002 schreef op maandag 22 januari 2024 @ 22:52:
[...]
Wanneer je 8.8.8.8 blocked, hoe "gaan ze dan via AGH"?
Dat werkt toch alleen i.c.m een NAT hairpin rule.

Klopt, ik redirect via een nat regel dns verkeer naar mn firewall.

[alex3305]

EverLast2002 schreef op maandag 22 januari 2024 @ 22:52:
[...]

Wanneer je 8.8.8.8 blocked, hoe "gaan ze dan via AGH"?
Dat werkt toch alleen i.c.m een NAT hairpin rule.

Niet per se. Als je 8.8.8.8 en 8.8.4.4 blockt pakt het device wel de door de DHCP aangeleverde DNS server. Maar dit is wel implementatie en dus apparaat afhankelijk.

[Hmmbob]

Ik vang in mijn firewall alles af wat denkt rechtstreeks naar buiten te gaan voor DNS requests, en redirect (MASQ) ze naar Adguard Home. Adguard is dan ook meteen de enige die wel naar buiten mag met zijn requests.

Die google apparaten denken dus antwoord te krijgen van 8.8.8.8, maar is in feite gewoon mijn Adguard die ze antwoord

[Helox-in-a-box]

Hmmbob schreef op dinsdag 23 januari 2024 @ 10:42:
Ik vang in mijn firewall alles af wat denkt rechtstreeks naar buiten te gaan voor DNS requests, en redirect (MASQ) ze naar Adguard Home. Adguard is dan ook meteen de enige die wel naar buiten mag met zijn requests.

Die google apparaten denken dus antwoord te krijgen van 8.8.8.8, maar is in feite gewoon mijn Adguard die ze antwoord

Werkt dit ook voor DNS-over-TLS?

[Hmmbob]

Hmmm, de regel staat op udp/53, dus dat denk ik niet eigenlijk

[EverLast2002]

Hmmbob schreef op dinsdag 23 januari 2024 @ 12:38:
Hmmm, de regel staat op udp/53, dus dat denk ik niet eigenlijk

Dan clone je die regel toch en maak je er poort 853 van.

[Hmmbob]

Snap ik, maar moet ik Adguard Home wel instellen voor TLS. Dat heb ik nog niet

[ahbart]

Ik heb Adguard Home al enige tijd draaien en ben daar heel positief over. Maar het valt me nu wel op dat dns resolving in Firefox op Debian veel trager is dan binnen Chromium. Soms bijna een seconde, terwijl andere browsers praktisch realtime zijn.
Ik kan hier gene vinger op leggen waar dit door komt. Mogelijk iets door de manier hoe Firefox omgaat met dns-over-http? Meen ik ergens te hebben gelezen?
Heeft iemand hier ervaring mee en eventueel een oplossing voor?

Dit zijn mijn Adguard Instellingen (mocht dat nuttig zijn hiervoor):

code:

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

Parallellen verzoeken aan

Bootstrap DNS-servers:
1.1.1.1
1.0.0.1
9.9.9.9
149.112.112.112
2606:4700:4700::1111
2606:4700:4700::1001
2620:fe::fe
2620:fe::fe:9
62.45.70.100
62.45.71.100

Private omgekeerde DNS-servers:
192.168.188.1 (Fritzbox-5590 modem)

Firefox 122.0 (64-bits)

Adguard draait in docker op een Intel Nuc met intern ip 192.168.188.69 en deze dns is ook ingesteld in de Fritz.
Iemand een idee hoe deze dns vertraging in Firefox is op te lossen?

[EverLast2002]

ahbart schreef op woensdag 7 februari 2024 @ 12:00:
Ik heb Adguard Home al enige tijd draaien en ben daar heel positief over. Maar het valt me nu wel op dat dns resolving in Firefox op Debian veel trager is dan binnen Chromium. Soms bijna een seconde, terwijl andere browsers praktisch realtime zijn.
Ik kan hier gene vinger op leggen waar dit door komt. Mogelijk iets door de manier hoe Firefox omgaat met dns-over-http? Meen ik ergens te hebben gelezen?
Heeft iemand hier ervaring mee en eventueel een oplossing voor?

Dit zijn mijn Adguard Instellingen (mocht dat nuttig zijn hiervoor):

code:

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

Parallellen verzoeken aan

Bootstrap DNS-servers:
1.1.1.1
1.0.0.1
9.9.9.9
149.112.112.112
2606:4700:4700::1111
2606:4700:4700::1001
2620:fe::fe
2620:fe::fe:9
62.45.70.100
62.45.71.100

Private omgekeerde DNS-servers:
192.168.188.1 (Fritzbox-5590 modem)

Firefox 122.0 (64-bits)

Adguard draait in docker op een Intel Nuc met intern ip 192.168.188.69 en deze dns is ook ingesteld in de Fritz.
Iemand een idee hoe deze dns vertraging in Firefox is op te lossen?

waarom heb je ZOVEEL bootstrap servers ingevuld?
Twee (of drie) is al voldoende, bijv 1.0.0.1 en 9.9.9.9
Bootstrap servers zijn alleen nodig wanneer AGH zelf e.e.a. moet resolven/checken.

En ik neem aan dat die "(Fritzbox-5590 modem)" vermelding letterlijk er niet zo in staat maar dat je dit zelf even voor ons hebt gedaan...?

[ahbart]

EverLast2002 schreef op woensdag 7 februari 2024 @ 12:27:
[...]
waarom heb je ZOVEEL bootstrap servers ingevuld?
Twee (of drie) is al voldoende, bijv 1.0.0.1 en 9.9.9.9
Bootstrap servers zijn alleen nodig wanneer AGH zelf e.e.a. moet resolven/checken.

Ga ik aanpassen. dank.
Heeft het nog toegevoegde waarde om hier een ipv6 tussen te zetten?
Maar dat is niet de oplossing voor mij Firefox probleem denk ik?

En ik neem aan dat die "(Fritzbox-5590 modem)" vermelding letterlijk er niet zo in staat maar dat je dit zelf even voor ons hebt gedaan...?

Klopt, alleen hier toegevoegd.

[EverLast2002]

ahbart schreef op woensdag 7 februari 2024 @ 12:32:
[...]

Ga ik aanpassen. dank.
Heeft het nog toegevoegde waarde om hier een ipv6 tussen te zetten?
Maar dat is niet de oplossing voor mij Firefox probleem denk ik?


[...]

Klopt, alleen hier toegevoegd.

Als je IPv6 gebruikt en je ISP ook dan zou ik dat wel erinzetten ja.

Ik heb DoH uitstaan in Firefox. Maar ik gebruik DoH nergens in mijn thuisnetwerk.
Dit is natuurlijk geen antwoord op je vraag, dat snap ik.

[alex3305]

@ahbart Misschien dat er iets mis is met je IPv6 resolving? Dat Firefox daar een voorkeur voor heeft, het niet lukt (timeout) en dat er dan naar IPv4 overgeschakeld wordt? Je zou dit kunnen testen door IPv6 resolven in AdGuard Home onder DNS settings (tijdelijk) uit te zetten.

Of uiteraard op je client

[ Voor 5% gewijzigd door alex3305 op 07-02-2024 13:04 ]

[ahbart]

alex3305 schreef op woensdag 7 februari 2024 @ 13:04:
@ahbart Misschien dat er iets mis is met je IPv6 resolving? Dat Firefox daar een voorkeur voor heeft, het niet lukt (timeout) en dat er dan naar IPv4 overgeschakeld wordt? Je zou dit kunnen testen door IPv6 resolven in AdGuard Home onder DNS settings (tijdelijk) uit te zetten.

Of uiteraard op je client

Dus: "Oplossen ipv6-adressen uitschakelen"?

Ja, dan gaat het heeel snel! Waar zijn mijn instellingen dan fout? Waar moet ik zoeken?
Ik heb nu bij Bootstrap:

code:

1.1.1.1
9.9.9.9
2606:4700:4700::1001
2620:fe::fe:9

[alex3305]

ahbart schreef op woensdag 7 februari 2024 @ 13:46:
[...]

Dus: "Oplossen ipv6-adressen uitschakelen"?

Yes

Ja, dan gaat het heeel snel! Waar zijn mijn instellingen dan fout? Waar moet ik zoeken?

Dat vermoeden had ik al. Je kunt een IPv6 Test doen om te kijken of je instellingen goed staan. Of gewoon IPv6 in Firefox uitschakelen.

[ahbart]

alex3305 schreef op woensdag 7 februari 2024 @ 13:52:
[...]

Yes
[...]
Dat vermoeden had ik al. Je kunt een IPv6 Test doen om te kijken of je instellingen goed staan. Of gewoon IPv6 in Firefox uitschakelen.

Ik zou er de voorkeur voor hebben om het op te lossen.
Dit is het resultaat van de ipv6 test:

Ik zie niets opvallend toch?

Edit:
Ping test ziet er niet goed uit voor ipv6

IPv6 niet goed werkend in de Fritz? Of is dit een dns ding?

[ Voor 21% gewijzigd door ahbart op 07-02-2024 14:34 ]

[alex3305]

ahbart schreef op woensdag 7 februari 2024 @ 14:29:
[...]

Ik zou er de voorkeur voor hebben om het op te lossen.
Dit is het resultaat van de ipv6 test:
[Afbeelding]
Ik zie niets opvallend toch?

Nee. In principe niets geks. En ik ben bang dat het ook niet in Adguard Home zit

Je zou eventueel nog met wat command line tools kunnen testen hoe daar bepaalde URL's resolven? En anders wellicht een apart topic hiervoor aanmaken?

[ahbart]

alex3305 schreef op woensdag 7 februari 2024 @ 14:34:
[...]

Nee. In principe niets geks. En ik ben bang dat het ook niet in Adguard Home zit

Je zou eventueel nog met wat command line tools kunnen testen hoe daar bepaalde URL's resolven? En anders wellicht een apart topic hiervoor aanmaken?

Ik had nog een ping test ge-edit hierboven. Daar lijkt wel iets mis mee. Ik open een apart topic.
Edit: Ik kom er achter dat het een dns probleem is op mij debian laptop. domdom
Dank voor het mee nadenken!!

[ Voor 10% gewijzigd door ahbart op 07-02-2024 15:34 ]

[BThomas]

Hmmbob schreef op donderdag 10 december 2020 @ 08:19:
[...]
Zo heb ik hier in huis veelal statische IPs - zeker voor de apparaten van mijn kinderen. Die heb ik in een aparte client groep staan waar adblocking nog veel stricter is en Google Safe Search afgedwongen wordt.

Hoe krijg ik dit voor elkaar in ADGUARD? En dan bedoel ik een onderscheid in clients qua filters

[ Voor 35% gewijzigd door BThomas op 28-02-2024 19:16 ]

[alex3305]

BThomas schreef op woensdag 28 februari 2024 @ 17:53:
[...]

Hoe krijg ik dit voor elkaar in ADGUARD? En dan bedoel ik een onderscheid in clients qua filters

Onder Settings > Client Settings kun je onder Persistent clients groepen aanmaken die je alternatieve regels geeft.

[Hmmbob]

Jupz, dat dus.

[Ati_]

Iemand hier evaring met een xperiabox van KPN? Onder 'Internetverbinding' > 'DNS' heb ik als 'Primaire DNSv4-service' mijn Adguard IP ingevuld, maar zodra ik dit opsla kan ik niks meer resolven op mijn apparaten. Wanneer ik de Adguard DNS handmatig op een Windows VM instel dan werkt het wel netjes.

[glaswerk]

Ati_ schreef op donderdag 29 februari 2024 @ 19:19:
Iemand hier evaring met een xperiabox van KPN? Onder 'Internetverbinding' > 'DNS' heb ik als 'Primaire DNSv4-service' mijn Adguard IP ingevuld, maar zodra ik dit opsla kan ik niks meer resolven op mijn apparaten. Wanneer ik de Adguard DNS handmatig op een Windows VM instel dan werkt het wel netjes.

Ik heb Experiabox 12 (met oude firmware/UI nog), onder primary DNSv4 AdGuard, secondary leeg. Gaat goed.

[gerritjan]

Ati_ schreef op donderdag 29 februari 2024 @ 19:19:
Iemand hier evaring met een xperiabox van KPN? Onder 'Internetverbinding' > 'DNS' heb ik als 'Primaire DNSv4-service' mijn Adguard IP ingevuld, maar zodra ik dit opsla kan ik niks meer resolven op mijn apparaten. Wanneer ik de Adguard DNS handmatig op een Windows VM instel dan werkt het wel netjes.

Onbekend met dat KPN-ding, maar moet je niet de DNS-settings ergens in een DHCP-menu instellen?
Je wilt (neem ik aan) dat je apparaten het Adguard-ip als DNS gaat gebruiken.

[Glassertje]

Update AdGuard Home v0.107.45

[EverLast2002]

Ati_ schreef op donderdag 29 februari 2024 @ 19:19:
Iemand hier evaring met een xperiabox van KPN? Onder 'Internetverbinding' > 'DNS' heb ik als 'Primaire DNSv4-service' mijn Adguard IP ingevuld, maar zodra ik dit opsla kan ik niks meer resolven op mijn apparaten. Wanneer ik de Adguard DNS handmatig op een Windows VM instel dan werkt het wel netjes.

ExperiaBox standaard zetten met KPN DNS erin.
Wat heb je als DNS ingevuld in AdGuard zelf? Daar zou je ExperiaBox moeten staan als DNS (en Gateway).
En wat iemand al aangaf, je moet AGH als DNS/Gateway met DHCP meegeven aan je clients.

[Redbaard]

Bij mij lukt de upgrade helaas niet, zelfde probleem was vorige keer. Namelijk te weinig diskspace. Draai adguard als LXC container op proxmox (https://tteck.github.io/Proxmox/). Had de disk een tijdje terug al vergroot naar 3gb. Kennlijk loopt het toch vol. Meer mensen hier ervaring mee?

[lolgast]

@Redbaard Blijkbaar log je te veel voor de hoeveelheid diskspace die je hebt gegeven. Je zou ook je /tmp folder eens leeg kunnen gooien. Als blijkt dat die vaak volloopt kun je die met blijvoorbeeld crontab periodiek laten legen. Ik heb zelf twee Alpine LXC containers voor Adguard en loop nooit tegen een volle schijf aan. Beide zitten op minder dan 1 GB diskspace in use

[Redbaard]

lolgast schreef op vrijdag 8 maart 2024 @ 14:21:
@Redbaard Blijkbaar log je te veel voor de hoeveelheid diskspace die je hebt gegeven. Je zou ook je /tmp folder eens leeg kunnen gooien. Als blijkt dat die vaak volloopt kun je die met blijvoorbeeld crontab periodiek laten legen. Ik heb zelf twee Alpine LXC containers voor Adguard en loop nooit tegen een volle schijf aan. Beide zitten op minder dan 1 GB diskspace in use

Zal dan even naar de logging kijken want als ik in de console naar de tmp folder ga en ls doe dan krijg ik geen files te zien.

Update: kennelijk toch te veel logs. na het verwijderen weer minder dan 1gb. Had 90dagen, nu teruggezet naar 30dagen.

[ Voor 8% gewijzigd door Redbaard op 08-03-2024 15:35 ]

[gerritjan]

EverLast2002 schreef op donderdag 7 maart 2024 @ 12:07:
[...]

ExperiaBox standaard zetten met KPN DNS erin.
Wat heb je als DNS ingevuld in AdGuard zelf? Daar zou je ExperiaBox moeten staan als DNS (en Gateway).
En wat iemand al aangaf, je moet AGH als DNS/Gateway met DHCP meegeven aan je clients.

bij gateway moet het IP van de Experiabox blijven staan.

[Wachten...]

Mag ik vragen hoe anderen hun Adguard met Unbound hebben ingesteld?

Ik heb nog best een hoge responstijd vindt ik (circa 30ms)
Ik heb als DNS upstream servers enkel de unbound en 1.1.1.1 ingevoerd, maar ik heb het idee dat ik daar nog wat andere servers bij moet gooien.



Wat is jullie ervaring hiermee, en/of hebben jullie nog andere tips waarmee in de response tijd kan verbeteren?

[Villager]

Wachten... schreef op zondag 10 maart 2024 @ 16:42:
Mag ik vragen hoe anderen hun Adguard met Unbound hebben ingesteld?

Ik heb nog best een hoge responstijd vindt ik (circa 30ms)
Ik heb als DNS upstream servers enkel de unbound en 1.1.1.1 ingevoerd, maar ik heb het idee dat ik daar nog wat andere servers bij moet gooien.

[Afbeelding]

Wat is jullie ervaring hiermee, en/of hebben jullie nog andere tips waarmee in de response tijd kan verbeteren?

Ik heb een responstijd van 60ms in Adguard. Ik gebruik DNS over TLS naar Quad9 en Cloudflare. Heb ook maar krap 5% geblokkeerd door filters.

[Hmmbob]

Villager schreef op zondag 10 maart 2024 @ 16:48:
[...]


Ik heb een responstijd van 60ms in Adguard. Ik gebruik DNS over TLS naar Quad9 en Cloudflare. Heb ook maar krap 5% geblokkeerd door filters.

Whoa, wat een getallen! Dat kan echt stukken beter, ook met DoT (Quad9 pakt bij mij 55% van de requests, en zit op 7ms responsetijd)



Overigens pakt de top-3 van de domeinen zo'n 22% van alle DNS requests, en dat is naar de cloud van wat slimme apparaten hier in huis.

[ Voor 10% gewijzigd door Hmmbob op 10-03-2024 17:01 ]

[Wachten...]

Villager schreef op zondag 10 maart 2024 @ 16:48:
[...]


Ik heb een responstijd van 60ms in Adguard. Ik gebruik DNS over TLS naar Quad9 en Cloudflare. Heb ook maar krap 5% geblokkeerd door filters.

Ja ik zie nu ook dat er maar 1 boosdoener is. Dat is de Roborock stofzuiger. Die gooit roet in het eten voor mijn response tijden.
Gemiddeld in de Query log zie ik alles onder de 1ms (zeer snel dus). Echter krijg ik hoge responstijden van mqtt-eu-2.roborock.com Ik blokkeer volledige toegang voor de Roborock, omdat ik alles lokaal afhandel.

Is er een manier om deze request eruit te halen? Dit geeft mij echt een verkeerd beeld van de Adguard response tijden.

[Wachten...]

Hmmbob schreef op zondag 10 maart 2024 @ 16:59:
[...]

Whoa, wat een getallen! Dat kan echt stukken beter, ook met DoT (Quad9 pakt bij mij 55% van de requests, en zit op 7ms responsetijd)

[Afbeelding]

Overigens pakt de top-3 van de domeinen zo'n 22% van alle DNS requests, en dat is naar de cloud van wat slimme apparaten hier in huis.

Gebruik jij ook unbound?

En ik zie dus in de Query log dat de meeste aanvragen dus onder de 1ms zijn. Het zijn af en toe aanvragen zoals Reddit momenteel of Roborock die roet in het eten gooien.

Ik ben benieuwd waar dit vandaag komt, en of ik dit kan verbeter. Heeft het nog nut om meer upstream servers toe te voegen als je Unbound gebruikt?

Overigens heb ik de Load balancing optie aan staan i.p.v. parallel request. geen idee of dat nog een verschil kan maken, echter weet ik wel dat bepaalde settings anders zijn met Unbound

[ Voor 9% gewijzigd door Wachten... op 10-03-2024 17:07 ]

[Hmmbob]

Wachten... schreef op zondag 10 maart 2024 @ 17:06:
Gebruik jij ook unbound?

Nee. Scherp.

(Ik snap de toegevoegde waarde van Unbound ook nog niet icm Adguard, maar misschien dat ik daar de enige in ben?)

[ Voor 27% gewijzigd door Hmmbob op 10-03-2024 17:08 ]

[Villager]

Wachten... schreef op zondag 10 maart 2024 @ 17:06:
[...]


Gebruik jij ook unbound?

En ik zie dus in de Query log dat de meeste aanvragen dus onder de 1ms zijn. Het zijn af en toe aanvragen zoals Reddit momenteel of Roborock die roet in het eten gooien.

Ik ben benieuwd waar dit vandaag komt, en of ik dit kan verbeter. Heeft het nog nut om meer upstream servers toe te voegen als je Unbound gebruikt?

Overigens heb ik de Load balancing optie aan staan i.p.v. parallel request. geen idee of dat nog een verschil kan maken, echter weet ik wel dat bepaalde settings anders zijn met Unbound

In mijn geval is het de Brother printer die roet in het eten gooit. Hij staat 'uit', maar zie regelmatig request er naar toe die 12-16 seconden responstijd geven in de logfiles.

[Wachten...]

Hmmbob schreef op zondag 10 maart 2024 @ 17:07:
[...]

Nee. Scherp.

(Ik snap de toegevoegde waarde van Unbound ook nog niet icm Adguard, maar misschien dat ik daar de enige in ben?)

Privacy en snelheid zouden de voornaamste reden moeten zijn lijkt mij.

Maar kun je het uitleggen waarom je geen voordelen ziet? Ik de Pihole topic wordt ook bijna altijd unbound gebruikt door Tweakers (zover ik me herinner)

[Hmmbob]

Waarom zou ik een extra dns server nodig hebben die de requests vanaf Adguard (wat ook een DNS server is) naar dezelfde hosts doorstuurt als dat wat Adguard zelf ook kan?

Ik zie niet in hoe unbound daarin voor meer privacy zou zorgen. Die requests komen nog steeds vanaf je eigen IP, toch?

[ Voor 26% gewijzigd door Hmmbob op 10-03-2024 19:57 ]

[Glassertje]

Hmmbob schreef op zondag 10 maart 2024 @ 19:53:
Waarom zou ik een extra dns server nodig hebben die de requests vanaf Adguard (wat ook een DNS server is) naar dezelfde hosts doorstuurt als dat wat Adguard zelf ook kan?

Ik zie niet in hoe unbound daarin voor meer privacy zou zorgen. Die requests komen nog steeds vanaf je eigen IP, toch?

Adguard werkt met publieke dns servers, terwijl unbound zijn informatie haalt van de root servers, waardoor dns request info binnenshuis blijft.

[ Voor 4% gewijzigd door Glassertje op 10-03-2024 20:32 ]

[Hmmbob]

Glassertje schreef op zondag 10 maart 2024 @ 20:31:
[...]

Adguard werkt met publieke dns servers, terwijl unbound zijn informatie haalt van de root servers, waardoor dns request info binnenshuis blijft.

Ah zo. Maar als het zo'n performance impact heeft als hierboven, dan zou ik het durven overslaan....

[lolgast]

@Hmmbob
lolgast in "[Adguard Home] Ervaringen & discussie"

[Villager]

Hmmbob schreef op zondag 10 maart 2024 @ 20:37:
[...]

Ah zo. Maar als het zo'n performance impact heeft als hierboven, dan zou ik het durven overslaan....

Ik probeer je niet over te halen om Unbound te gaan gebruiken. Het is een kwestie van:
1. vertrouw je de huidige DNS providers en is de performance oke, dan gewoon zonder Unbound verder gaan;
2. vertrouw je ze wat minder en je wilt een goeie performance dan wel naar Unbound.

In mijn geval zag ik dat één enkele devices heel lange responstijden hadden. Dat had ik mogelijk in Adguard hetzelfde gehad. Heb het gisteren opgelost met wat settings aanpassen en zit nu op 15ms (met gebruik DNS over TLS).
Ik heb best wel zitten stoeien met zoeken naar de juiste settings voor Unbound (en nog steeds dus ), dus kan goed begrijpen dat je niet begint aan Unbound.

[Wachten...]

Hmmbob schreef op zondag 10 maart 2024 @ 20:37:
[...]

Ah zo. Maar als het zo'n performance impact heeft als hierboven, dan zou ik het durven overslaan....

Het heeft normaal gesproken juist geen (negatieve) performance impact. De meeste aanvragen zitten ergens op de 0.20ms, echt extreem snel dus. Er zijn slechts een paar aanvragen die roet in het eten gooien. Ik heb deze aanvragen even geblokkeerd en ik zie mijn response tijden nu zakken.

Ik denk oprecht dat ik ergens op de 1 a 2ms uit komt gemiddeld gezien net als @lolgast

En zoals anderen al aangeven. Vertrouw je de partij die de aanvragen afhandelt. Dat is net als dat de ene hun mail wel bij Google willen houden, en anderen absoluut niet 😊

[dajappie]

Wachten... schreef op maandag 11 maart 2024 @ 09:43:
[...]


Het heeft normaal gesproken juist geen (negatieve) performance impact. De meeste aanvragen zitten ergens op de 0.20ms, echt extreem snel dus. Er zijn slechts een paar aanvragen die roet in het eten gooien. Ik heb deze aanvragen even geblokkeerd en ik zie mijn response tijden nu zakken.

Ik denk oprecht dat ik ergens op de 1 a 2ms uit komt gemiddeld gezien net als @lolgast

En zoals anderen al aangeven. Vertrouw je de partij die de aanvragen afhandelt. Dat is net als dat de ene hun mail wel bij Google willen houden, en anderen absoluut niet 😊

0.20 ms is neem ik aan alleen als het uit je lokale cache komt. En de "Average processing time" op het dashboard van een paar ms (bij mij momenteel 1 ms) is het gemiddelde over alle requests incl. degene die gecached zijn. De voornaamste statistiek voor mij is de "Average upstream response time" die per upstream DNS-server het gemiddelde geeft, die zijn ook aardig in lijn met een SmokePing DNS-probe die enkele standaard hosts bevraagd. De uitschieters naar vage websites met trage DNS-servers zouden op de grote hoop geen enorme invloed moeten hebben mits je overall volume maar hoog genoeg is lijkt me.

[Wachten...]

dajappie schreef op maandag 11 maart 2024 @ 11:04:
[...]


0.20 ms is neem ik aan alleen als het uit je lokale cache komt. En de "Average processing time" op het dashboard van een paar ms (bij mij momenteel 1 ms) is het gemiddelde over alle requests incl. degene die gecached zijn. De voornaamste statistiek voor mij is de "Average upstream response time" die per upstream DNS-server het gemiddelde geeft, die zijn ook aardig in lijn met een SmokePing DNS-probe die enkele standaard hosts bevraagd. De uitschieters naar vage websites met trage DNS-servers zouden op de grote hoop geen enorme invloed moeten hebben mits je overall volume maar hoog genoeg is lijkt me.

Ja dat komt uiteraard vanuit de cache. Dat is ook heel het idee er van

Ik zal vast nog wel wat kunnen verbeteren in mijn setup hoor. Want mag ik vragen wat de server response tijden zijn bij jou?

Bij mij zijn die nog vrij hoog

[Glassertje]

Wachten... schreef op maandag 11 maart 2024 @ 12:21:
[...]


Ja dat komt uiteraard vanuit de cache. Dat is ook heel het idee er van

Ik zal vast nog wel wat kunnen verbeteren in mijn setup hoor. Want mag ik vragen wat de server response tijden zijn bij jou?

Bij mij zijn die nog vrij hoog
[Afbeelding]

Ik vraag me alleen af waarom je unbound gebruikt? Je hebt er ook publieke dns bij staan. Of mis ik iets?

[gielie]

Ik heb even een vraag.
Mijn situatie is ik heb adguard DNS draaien op 192.168.1.2 (geen DHCP)(router is 192.168.1.1), dit werkt goed en alle apparaten in mijn netwerk komen ook voorbij in de query log.
Nu heb ik een quest network die draait op 192.168.2.1 en de DNS ingesteld op 192.168.1.2, adguard dus, dit werkt goed, althans, apparaten in mijn guest netwerk gebruiken deze DNS en alles wat geblokkeerd moet wordt ook geblokkeerd maar de apparaten in de dit netwerk komen niet in mijn query log te staan, hoe regel ik dit, kan dit überhaupt?

[Wachten...]

Glassertje schreef op maandag 11 maart 2024 @ 12:45:
[...]

Ik vraag me alleen af waarom je unbound gebruikt? Je hebt er ook publieke dns bij staan. Of mis ik iets?

Ik ben geen DNS guru, maar zover ik weet kijkt hij altijd eerst naar de unbound regels, en als hij deze niet kan vinden, dan kijkt hij naar de alternatieve opgegeven adressen. Het is dus meer als backup.

maar corrigeer me als ik iets verkeerds zeg.

[Glassertje]

Wachten... schreef op maandag 11 maart 2024 @ 12:53:
[...]


Ik ben geen DNS guru, maar zover ik weet kijkt hij altijd eerst naar de unbound regels, en als hij deze niet kan vinden, dan kijkt hij naar de alternatieve opgegeven adressen. Het is dus meer als backup.

maar corrigeer me als ik iets verkeerds zeg.

Dat is niet waar, anders had je unbound wel als snelste gestaan. AdGuard kijkt naar de snelste server. De bedoeling van unbound is juist om alleen die te gebruiken. Je kan wel als fail over er 1 in de backup zetten. Mijn gemiddelde procestijd is 7. Heb er gisteren aan zitten rommelen maar nu staat die al zo. Internet is lekker snel, dus maak me er geen zorgen om.

[Wachten...]

Glassertje schreef op maandag 11 maart 2024 @ 13:00:
[...]

Dat is niet waar, anders had je unbound wel als snelste gestaan. AdGuard kijkt naar de snelste server. De bedoeling van unbound is juist om alleen die te gebruiken. Je kan wel als fail over er 1 in de backup zetten. Mijn gemiddelde procestijd is 7. Heb er gisteren aan zitten rommelen maar nu staat die al zo. Internet is lekker snel, dus maak me er geen zorgen om.

[Afbeelding]

Je zal ongetwijfeld gelijk hebben. het is ook maar van wat ik ervan weet en ooit opgepakt heb. Zoals gezegd ben ik geen DNS guru, en leer ik graag.

De response tijd bij jou is wel aanzienlijk sneller. Maak jij gebruik van load balancing of parallel request in de DNS settings?

En zijn er überhaupt nog andere settings die goed zijn om naar te kijken?

En wat doet de verwijzing naar je router 192.168.50.1?

[Glassertje]

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


Je zal ongetwijfeld gelijk hebben. het is ook maar van wat ik ervan weet en ooit opgepakt heb. Zoals gezegd ben ik geen DNS guru, en leer ik graag.

De response tijd bij jou is wel aanzienlijk sneller. Maak jij gebruik van load balancing of parallel request in de DNS settings?

En zijn er überhaupt nog andere settings die goed zijn om naar te kijken?

En wat doet de verwijzing naar je router 192.168.50.1?

De reden dat de procestijd van unbound zo hoog is, is omdat AdGuard Home de publieke DNS gebruikt. Kan je ook zien in je log. Als unbound niks doet, gaat procestijd omhoog. Ik gebruik load balancing.

Ik heb dezelfde handleiding gevolgt als die jij hebt, als je config nog hetzelfde is. Heb alleen de TTL verwijderd, omdat ik hier niet mee ga rommelen.

Ik heb bij upstream DNS het volgende ingevuld.wordt hier ook uitgelegd.

Dit is o.a. dat ik device namen in AGH zie ipv ip adres en verwijzing voor lokale domeinen.

127.0.0.1:5335
[/local/]192.168.50.1:53
[/in-addr.arpa/]192.168.50.1
[/ip6.arpa/]192.168.50.1

[ Voor 6% gewijzigd door Glassertje op 11-03-2024 13:20 ]

[Wachten...]

Glassertje schreef op maandag 11 maart 2024 @ 13:18:
[...]

De reden dat de procestijd van unbound zo hoog is, is omdat AdGuard Home de publieke DNS gebruikt. Kan je ook zien in je log. Als unbound niks doet, gaat procestijd omhoog. Ik gebruik load balancing.


[...]

Maar haal je dit probleem weg door enkel unbound in te voeren bij DNS upstream servers?

[Glassertje]

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


Maar haal je dit probleem weg door enkel unbound in te voeren bij DNS upstream servers?

Probeer gewoon alleen unbound in te stellen en kijk morgen, of vanavond en je zal zien dat die niet zo hoog is als nu. als je unbound niet gebruikt wordt, kan je ook geen cache opbouwen. Daar wordt die namelijk sneller van.

[Wachten...]

Glassertje schreef op maandag 11 maart 2024 @ 13:18:
[...]


Ik heb bij upstream DNS het volgende ingevuld.wordt hier ook uitgelegd.


[...]

Ik moet dit eens rustig lezen, maar zover ik het nu al lees is het iets te complex voor mij. Ik ben wat dat betreft niet genoeg thuis is alles, en is dus wat lastig om doorheen te komen en te begrijpen ben ik bang.

[Wachten...]

Glassertje schreef op maandag 11 maart 2024 @ 13:23:
[...]

Probeer gewoon alleen unbound in te stellen en kijk morgen, of vanavond en je zal zien dat die niet zo hoog is als nu. als je unbound niet gebruikt wordt, kan je ook geen cache opbouwen. Daar wordt die namelijk sneller van.

Ga ik doen, heb ze er net uitgegooid, even zien wat dat doet

Heeft het overigens nog zin om de cache opties in te stellen in de DNS settings als je Unbound gebruikt?

[Villager]

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


Ga ik doen, heb ze er net uitgegooid, even zien wat dat doet

Heeft het overigens nog zin om de cache opties in te stellen in de DNS settings als je Unbound gebruikt?

Ik gebruik Unbound en heb alle caching in Adguard uitgezet. Anders heb je dubbele caching, volgens mij.

[Glassertje]

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


Ga ik doen, heb ze er net uitgegooid, even zien wat dat doet

Heeft het overigens nog zin om de cache opties in te stellen in de DNS settings als je Unbound gebruikt?

Beter van niet, Unbound cached ook al. Ik heb het eens een keer ingeschakeld optmistisch cache en toen had ik vage problemen.

En echt meerwaarde is er niet.

[ Voor 32% gewijzigd door Glassertje op 11-03-2024 13:30 ]

[Glassertje]

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


Ik moet dit eens rustig lezen, maar zover ik het nu al lees is het iets te complex voor mij. Ik ben wat dat betreft niet genoeg thuis is alles, en is dus wat lastig om doorheen te komen en te begrijpen ben ik bang.

Wat voor router gebruik je?

[Wachten...]

Glassertje schreef op maandag 11 maart 2024 @ 13:31:
[...]
Wat voor router gebruik je?

@Villager Bedankt voor de cache reactie
Geldt dat ook voor de TTL instellingen dan?

Ik gebruik een Unifi Dream Machine.
Daar verwijs ik van alle netwerken naar de Adguard DNS
Ik heb dus geen alternatieve DNS instelling en gebruik enkel Adguard.

[dajappie]

Wachten... schreef op maandag 11 maart 2024 @ 12:21:
[...]


Ja dat komt uiteraard vanuit de cache. Dat is ook heel het idee er van

Ik zal vast nog wel wat kunnen verbeteren in mijn setup hoor. Want mag ik vragen wat de server response tijden zijn bij jou?

Bij mij zijn die nog vrij hoog
[Afbeelding]

Tuurlijk, zie onder. KPN 1 Gbit/s glas, 1 Gbit/s intern netwerk, AG draait in een Docker container op een NAS. geen Unbound, 4 upstream DNS via DoT, parallel requests, optimistic caching. Avg. request time 1 ms.

tls://8.8.4.4:853 31 ms
tls://8.8.8.8:853 27 ms
tls://1.0.0.1:853 23 ms
tls://1.1.1.1:853 18 ms

[Glassertje]

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


@Villager Bedankt voor de cache reactie
Geldt dat ook voor de TTL instellingen dan?

Ik gebruik een Unifi Dream Machine.
Daar verwijs ik van alle netwerken naar de Adguard DNS
Ik heb dus geen alternatieve DNS instelling en gebruik enkel Adguard.

TTL kun je het best laten wat het is. Als een website van ip veranderd, zetten ze de TTL omlaag zodat je snel weer op de nieuwe website zit. Als je hier iets invuld, dan kun je wachten tot je tijd voorbij is. Je kan er alleen maar problemen van krijgen.

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

Deze 2 zoals in voorbeeld, is voor Reverse DNS Gewoon op je gemak lezen. doe ik ook.

[Villager]

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


@Villager Bedankt voor de cache reactie
Geldt dat ook voor de TTL instellingen dan?

Yep, alles staat uit of is leeg in 'DNS cache configuratie'. Het lijkt mij het beste als dit allemaal in Unbound geregeld wordt. Daar staan sommige waarden, zoals TTL, op default waarden. Je kunt ze aanpassen, maar dat heb ik (nog) niet gedaan.

[ Voor 25% gewijzigd door Villager op 11-03-2024 13:58 ]

[Wachten...]

Glassertje schreef op maandag 11 maart 2024 @ 13:42:
[...]

TTL kun je het best laten wat het is. Als een website van ip veranderd, zetten ze de TTL omlaag zodat je snel weer op de nieuwe website zit. Als je hier iets invuld, dan kun je wachten tot je tijd voorbij is. Je kan er alleen maar problemen van krijgen.


[...]

Deze 2 zoals in voorbeeld, is voor Reverse DNS Gewoon op je gemak lezen. doe ik ook.

Ik ga er straks eens even rustig voor zitten en het lezen.

Je kan daarmee dan ook zeker de cliënt namen krijgen van je router zoals je eerder vermelde zeker?

[Glassertje]

Wachten... schreef op maandag 11 maart 2024 @ 15:09:
[...]


Ik ga er straks eens even rustig voor zitten en het lezen.

Je kan daarmee dan ook zeker de cliënt namen krijgen van je router zoals je eerder vermelde zeker?

Klopt.

[Villager]

Wel grappig trouwens dat iemand een vraag stelt over Unbound en dat ik er dan eigenlijk weer een 'ingezogen' wordt om een paar dingen bij mezelf te checken. Zoals aangegeven gebruik ik DNS over TLS, maar kon eigenlijk geen goeie test vinden. Ja, de https://on.quad9.net/ pagina, maar daar staat dan YES, maar niet of je TLS verbinding werkt. Zojuist kwam ik dit commando tegen. Na runnen krijg ik DOT als respons. Nu weet ik het zeker :-)

code:

dig +short txt proto.on.quad9.net.

[Wachten...]

Glassertje schreef op maandag 11 maart 2024 @ 15:31:
[...]

Klopt.

Ik heb even verder gelezen en dacht dat ik het begreep. Met de Enable clients' hostname resolution zou ik de client namen moeten krijgen. Deze stond al aan, maar ik zie gewoon ip adressen.

Ik dacht misschien moet hij communiceren met mijn router, dus heb bij Private reverse DNS servers mijn router IP ingevoerd, maar zonder gewenst resultaat.

[Glassertje]

Wachten... schreef op maandag 11 maart 2024 @ 16:54:
[...]


Ik heb even verder gelezen en dacht dat ik het begreep. Met de Enable clients' hostname resolution zou ik de client namen moeten krijgen. Deze stond al aan, maar ik zie gewoon ip adressen.

Ik dacht misschien moet hij communiceren met mijn router, dus heb bij Private reverse DNS servers mijn router IP ingevoerd, maar zonder gewenst resultaat.

Ik zie alleen de host namen als ik die regels toevoeg in AGH en ook mijn router ip onder private reverse dns.

[Wachten...]

Ja ik zie dus voor sommige dingen nu namen onder het ip adres staan, maar ook van heel veel dingen niet.
Hij pakt dus wel iets op, maar lang niet alles.

Ik had verwacht dat hij dan direct alle namen vanuit de Unifi zou weergeven.

Als ik ook naar de cliënt list ga in Adguard dan zie ik bij sommige rDNS (dus die doet hij wel als het goed is)
Maar bij de meeste staat ARP.

[ Voor 24% gewijzigd door Wachten... op 11-03-2024 18:06 ]

[Wachten...]

@Glassertje

Hij heeft na een reboot wel wat meer gevonden, maar klopt het dat ik niet de namen zie die in Unifi staan?
Ik zie dus wel namen, maar ze heten anders dan dat ze in Unifi staan vermeld.

En als ik een nslookup doe op mijn windows, dan vindt hij sommige apparaten ook niet in de main lan, terwijl ze wel online zijn. (ik zie ze dus ook niet in adguard verschijnen. Het volgende krijg ik dan als melding.

*** adguard.local can't find 192.168.0.39: Non-existent domain

Ik heb het RFC1918 netwerk toegang gegeven tot de poorten van adguard en unbound, dus dat moet het probleem niet zijn.

Overigens geeft hij apparaten vanuit VLANS helemaal geen namen in Adguard

[ Voor 5% gewijzigd door Wachten... op 11-03-2024 20:05 ]

[alex3305]

Wachten... schreef op maandag 11 maart 2024 @ 16:54:
[...]

Ik dacht misschien moet hij communiceren met mijn router, dus heb bij Private reverse DNS servers mijn router IP ingevoerd, maar zonder gewenst resultaat.

Ook in ARPA formaat? Ik heb daar namelijk staan:

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

en in mijn upstream:

[//]192.168.1.1
[/lan/]192.168.1.1

De upstream configuratie is nodig om van hostname naar IP-adres te resolven, en de reverse is nodig om van een IP weer een hostname te kunnen maken. Waarbij lan mijn interne domain is. Dit moet ik nog een keer aanpassen, maar goed.

[Wachten...]

alex3305 schreef op maandag 11 maart 2024 @ 21:34:
[...]

Ook in ARPA formaat? Ik heb daar namelijk staan:

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

en in mijn upstream:

[//]192.168.1.1
[/lan/]192.168.1.1

De upstream configuratie is nodig om van hostname naar IP-adres te resolven, en de reverse is nodig om van een IP weer een hostname te kunnen maken. Waarbij lan mijn interne domain is. Dit moet ik nog een keer aanpassen, maar goed.

Ja ik weet dus niet zo goed wat ik daar nu precies in moet voeren, aangezien ik ook unbound heb.
ik heb dus in de upstream DNS servers

code:

127.0.0.1:5353

moet ik dan daarbij gewoon verwijzen naar mijn router? dus

code:

127.0.0.1:5353
192.168.1.1
[/168.192.in-addr.arpa/]192.168.1.1

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

Dus zoals jij het hebt staan, zo zie ik het niet in de documentatie staat (of ik lees wat verkeerd)

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).

[ Voor 3% gewijzigd door Wachten... op 11-03-2024 22:19 ]

[Glassertje]

Wachten... schreef op maandag 11 maart 2024 @ 20:04:
@Glassertje

Hij heeft na een reboot wel wat meer gevonden, maar klopt het dat ik niet de namen zie die in Unifi staan?
Ik zie dus wel namen, maar ze heten anders dan dat ze in Unifi staan vermeld.

En als ik een nslookup doe op mijn windows, dan vindt hij sommige apparaten ook niet in de main lan, terwijl ze wel online zijn. (ik zie ze dus ook niet in adguard verschijnen. Het volgende krijg ik dan als melding.

*** adguard.local can't find 192.168.0.39: Non-existent domain

Ik heb het RFC1918 netwerk toegang gegeven tot de poorten van adguard en unbound, dus dat moet het probleem niet zijn.

Overigens geeft hij apparaten vanuit VLANS helemaal geen namen in Adguard

Ik heb geen flauw idee wat je allemaal aan het doen bent, kan je daar helaas niet verder mee helpen. 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.

[ Voor 7% gewijzigd door Glassertje op 12-03-2024 08:07 ]