:strip_exif()/i/2003594310.png?f=thumbmini)
:strip_icc():strip_exif()/u/506130/keitjes.jpg?f=community)
- edit: ik gebruik nu een zelf geinstalleerde Debian lxc, de vorige keer had ik een Proxmox-helper-script versie gebruikt. Misschien dat in die laatste toch net effe andere pakketten zitten (of ontbreken).
:strip_exif()/u/834/bianchi_logo2.gif?f=community){kind=logo}
/u/16711/crop60a011a7ee516_cropped.png?f=community)
:strip_exif()/u/476997/ceetava60x60.gif?f=community)
:strip_icc():strip_exif()/u/531266/crop60146ed3278a5_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/198189/crop67ecf5f08705a_cropped.jpg?f=community)
@Koepert Ik heb geen KPN, wel Proxmox en AGH in Debian LXC’s. Met ‘maar’ 256MB geheugen @EverLast2002 
Ik herken je problemen verder niet. Ook ik heb mijn TV uitgesloten van blocklists, maar ervaar geen problemen met streamen van content.
Maar, als het met Pihole niet speelt dan lijkt de oorzaak me vrij duidelijk. Enige wat je kunt doen is troubleshooten, denk dat het een vrij specifieke case zal worden met weinig vergelijkbare situaties op het internet
Ik herken je problemen verder niet. Ook ik heb mijn TV uitgesloten van blocklists, maar ervaar geen problemen met streamen van content. Maar, als het met Pihole niet speelt dan lijkt de oorzaak me vrij duidelijk. Enige wat je kunt doen is troubleshooten, denk dat het een vrij specifieke case zal worden met weinig vergelijkbare situaties op het internet
Excuus ik vergeet een stap in de historie
De Debian container heb ik gekilled omdat dit van AGH dus een vastloper maakte. Toen gekozen voor Alpine ivm lichtheid. Dat werkte wel, maar dus hakkelen, TOEN ben ik begonnen met RAM ophogen in de wetenschap dat dit voor Alpine niet nodig zou moeten zijn. Maar als stap in 1vd 3 logische oorzaken uitsluiten..
met "htop" in een lxc kun je zien hoe de load is. Of via de gui van Proxmox, dan moet die Alpine lxc staan te pieken met geheugen?:
[...]
Excuus ik vergeet een stap in de historie
Als je de adressen weglaat terwijl de fout in de adressen zit, kunnen we niet echt helpen
Je moet de global unicast adressen gebruiken. Kan je vanaf AGH pingen naar "ping6 ipv6.google.com"
:strip_exif()/f/image/cmCBrziMtqVqyweJRsMfhWVA.png?f=user_large)
@stormfly Was idd wel handig geweest. Ik kan pingen vanaf de Raspberry Pi.:
[...]
Als je de adressen weglaat terwijl de fout in de adressen zit, kunnen we niet echt helpen
Je moet de global unicast adressen gebruiken. Kan je vanaf AGH pingen naar "ping6 ipv6.google.com"
[Afbeelding]
Ik gebruik in mijn Fritzbox nu een fe80:: adres van 1 van de Raspberry Pi's. Maar volgens jouw beschrijving zou ik dus de 2a02 moeten gebruiken?
Ik heb de 2a02 en de fe80:: adressen niet tegelijk gebruikt, Dit heb ik alleen zo gedaan om mijn configuratie weer te geven.
Master:
Backup:
Gebruik mijn config maar en daarna horen we de resultaten wel ;-) Je hoeft het 2a02 adres maar op één plaats in te vullen in mijn config. Ik begrijp je verwarring nog niet helemaal
:strip_icc():strip_exif()/u/33065/crop59d32fcf38790_cropped.jpeg?f=community)
Deze config ook ff gepakt, maar die check voor pihole-ftl moet er wel uit natuurlijk voor AGH...:
[...]
Gebruik mijn config maar en daarna horen we de resultaten wel ;-) Je hoeft het 2a02 adres maar op één plaats in te vullen in mijn config. Ik begrijp je verwarring nog niet helemaal
Nadat ik dat gedaan had en het voor mijn situatie had aangepast (denk aan andere interface namen) werkt het nu prima! Dank hiervoor.
:strip_icc():strip_exif()/u/249279/crop5f1097e13cf2e_cropped.jpeg?f=community)
Ik gok dat je zelf recursing doet en dnssec gebruikt.
zie de discussie bij de collega's met pihole, met de uitleg van stormfly in "[Pi-Hole] Ervaringen & discussie"
Komt er op neer dat odido een fout heeft gemaakt, sommige dnssec implementaties zijn wat vergevingsgezinder dan andere
Aha, dat verklaart een hoop:
[...]
Ik gok dat je zelf recursing doet en dnssec gebruikt.
zie de discussie bij de collega's met pihole, met de uitleg van stormfly in "[Pi-Hole] Ervaringen & discussie"
Komt er op neer dat odido een fout heeft gemaakt, sommige dnssec implementaties zijn wat vergevingsgezinder dan andere
Ik gebruik inderdaad unbound
Dit zijn mijn upstream settings
code:
1
2
3
4
5
6
7
| # Unbound 127.0.0.1:5335 # Extra [///0.168.192.in-addr.arpa/]192.168.0.1 https://dns.quad9.net/dns-query tls://dns.quad9.net 9.9.9.9 |
Kan ik toevallig ook iets in de GUI aanpassen waardoor het werkt? Of moet ik echt in de config van unbound wat aanpassen zoals in de post aangegeven?
Als je dit kunt lezen, dan werkt mij Signature!
Arg!Hallo,
Ik heb een vraag over AdGuard Home icm Wireguard op een Unifi netwerk. Als ik in een verkeerd topic zit, hoor ik het graag.
Vraag;
Kunnen jullie mij helpen met instellingen mbt de combi Wireguard en AdGuard Home? Want met regelmaat werkt mijn VPN niet (als ik buitenshuis ben) en nu lijkt het dat wanneer ik thuis AdGuard uit zet, ik deze problemen niet heb. Dus denk dat het ergens door de AdGuard settings komt
Software;
Proxmox met Unifi (192.168.1.10) en AdGuard (192.168.1.12)
Android - WG Tunnel
Settings;
Unifi
Alle unifi hardware heeft een vast IP en een preferred DNS (192.168.1.12)
Settings - Internet - WAN - DNS Primary Server (9.9.9.9) en Secondary DNS (149.112.112.112)
Settings - Network - Default - DNS Server (192.168.1.12)
Settings - Routing - Static Routes
Name - WireGuard
Distance - 1
Destination Network - 192.168.2.1/32
Type - Next hop
Next Hop - 192.168.1.12
AdGuard
DNS Settings
https://dns.quad9.net/dns-query
tls://dns.quad9.net
Bootstrap DNS servers
9.9.9.9
149.112.112.112
WireGuard (vanuit Unifi Network Controler)
Use Alternate Address for Clients - MYDDNS.Hostname (desec.io)
DNS Server 1 - 192.168.1.12
Extra info
De VPN op mijn laptop, als ik op het netwerk zit. Werkt bijna altijd als ik het test.
Heb de zelfde VPN config files 3x in WG Tunnel, met twee verschillende DDNS servers én één keer mijn WAN adres, om de DDNS service uit te sluiten. (Zet ze niet tegelijk aan)
Het lijkt als ik Adguard uit zet, de VPN stabieler en beter werkt
Eenmaal buiten, bijvoorbeeld tijdens werk, werkt de VPN ineens niet meer en krijg ik niet meer actief.
Het heeft tot enkele weken al sinds begin dit jaar perfect gewerkt. En nu ineens enkele weken niet meer.
--edit--
Rond deze post vpn aangezet.(12:00 uur)
Rond 18:30 geen verbinding meer en geen mogelijkheid om te verbinden. Zowel op mijn mobiel als die van mijn vriendin (dus niet een telefoon probleem)
Nu thuis op wifi werkt het ook niet.
Adguard uit
Nog geen vpn...
Het lijkt dus misschien toch geen Adguard probleem
--edit--
VPN op laptop werkt
VPN op mobiel werkt niet
Als VPN aan staat, heb ik geen LAN toegang. Dus ik ga verder zoeken naar een Wireguard/ Unifi probleem.
Waarschijnlijk toch geen AdGuard probleem.
Excuus voor het vervuilen van het topic
Waarschijnlijk is het een WG Tunnel probleem. Ik heb net de WireGuard app gedownload en een export van en WG Tunnel in WireGuard geïmporteerd. En de vpn doet het wel!
De zelfde settings, andere app.
[ Voor 16% gewijzigd door RedRayMann op 19-04-2025 23:07 ]
Ik heb geen cache in AGH, wel in Technitium. Een lookup van AGH naar Technitium is gemiddeld 40us. Verwaarloosbaar dus
Hmmm leuk die tool kende ik niet ;-) tnx:
Ik heb geen cache in AGH, wel in Technitium. Een lookup van AGH naar Technitium is gemiddeld 40us. Verwaarloosbaar dus
:strip_icc():strip_exif()/u/146731/crop562615a0aa64c.jpeg?f=community)
Dat is ook exact mijn filosofie elke cache in het pad kan helpen versnellen. Leuk dat je de ervaringen deelt vergeet ook niet: Optimistic caching
Make AdGuard Home respond from the cache even when the entries are expired and also try to refresh them.
Het opzoeken van een record via root -> TLD -> authoritative is best een lang pad, je merkt ook duidelijk als de betreffende URL voor het eerst door unbound heen moet. Daarom is een DNS van je provider ook vaak snel omdat je daar profiteert van de landelijk cache.
- Client vraagt: Jij typt bijvoorbeeld www.example.nl in je browser.
- Cache check: Je pc checkt eerst of hij het IP-adres al kent (cache).
- DNS Resolver: Zo niet, dan vraagt je pc het aan een DNS resolver (meestal van je internetprovider).
- Root servers: De resolver vraagt eerst aan een root server: “Waar vind ik .nl?”
- TLD servers (.nl): De root server zegt: “Ga naar de .nl TLD servers.”
- TLD servers: De resolver vraagt bij de .nl server: “Waar is example.nl?”
- Authoritative server: De .nl server verwijst naar de authoritative DNS server voor example.nl.
- Ophalen IP: De resolver vraagt daar het echte IP-adres op.
- Terug naar client: De resolver geeft het IP-adres terug aan jouw pc.
- Connectie: Je pc maakt dan een verbinding met het IP-adres.
en het feit dat ze echt een loei snelle DNS farm hebben.
[ Voor 3% gewijzigd door stormfly op 25-04-2025 17:58 ]
https://github.com/Lissy93/AdGuardian-Term/releases
Leuk tooltje om realtime mee te kijken, screenshot van GitHub.
Leuk tooltje om realtime mee te kijken, screenshot van GitHub.
[ Voor 3% gewijzigd door stormfly op 26-04-2025 13:19 ]
Ik heb nog even lopen freubelen met tunning, zoals jullie mogelijk gelezen hebben is voor mij snelheid belangrijker dan ultieme privacy. Ik vertrouw KPN als provider, ook als ze loggen.
Minder dan 0ms is helaas niet haalbaar
/f/image/wmAEM2QFqMsXrtT1ceptLCR3.png?f=fotoalbum_large)
Hier zie je heel goed wat een warme cache doet, en hoe snel het KPN DNS cluster is. KPN staat elke dag met stip op nummer #1 in de 24hr statistiek. Overigens wel het secondary adres, niet het primary. Daarna komt Technititim en daarna pas Unbound. Ik ben erg blij met de Technitium tip die hier werd gedeeld @lolgast
Technitium en Unbound draaien samen om te bepalen welke van de twee de snelste is, uiteindelijk zal er één vervallen.
KPN heeft een ping tijd van 4 a 5 ms terwijl de localhost intern draait, toch is het antwoord sneller terug vanuit KPN dan vanuit Technitium of Unbound. Ik gebruik de optie voor parallelle requests, de snelste wint.
/f/image/Xwg7lXJBGsRuJemNd5MIiJNY.png?f=fotoalbum_large)
/f/image/C7iHcr12ISQSdgAvPiFtuVqk.png?f=fotoalbum_large)
Ik heb nog een overlay website gemaakt die de API output van AGH parsed, ik wil beter zien of iets uit cache komt. Draait in een klein docker container.
/f/image/X7gbwySauciaWJ2QyvoZi6vb.png?f=fotoalbum_large)
Alle ultrakorte TTL's zet ik op 5 minuten ipv bijvoorbeeld 30seconden.
/f/image/l6dJvQ9Ljz0BFjWj7aL9E0Vj.png?f=fotoalbum_large)
In Technitium heb ik de waardes iets verlaagd om prefetching iets eerder af te dwingen.
/f/image/CYwxVEx0o3GppMFLxXqvi3Ls.png?f=fotoalbum_large)
Serve stale wait time naar 0
/f/image/0uI4xlpoQ5xaIdhUQmdcEFcX.png?f=fotoalbum_large)
Unbound heb ik ook veel aan getuned voor een 4 core machine hieronder mijn config. Unbound gecompiled met libevent:
Minder dan 0ms is helaas niet haalbaar
:strip_exif()/f/image/wmAEM2QFqMsXrtT1ceptLCR3.png?f=user_large)
Hier zie je heel goed wat een warme cache doet, en hoe snel het KPN DNS cluster is. KPN staat elke dag met stip op nummer #1 in de 24hr statistiek. Overigens wel het secondary adres, niet het primary. Daarna komt Technititim en daarna pas Unbound. Ik ben erg blij met de Technitium tip die hier werd gedeeld @lolgast
Technitium en Unbound draaien samen om te bepalen welke van de twee de snelste is, uiteindelijk zal er één vervallen.
KPN heeft een ping tijd van 4 a 5 ms terwijl de localhost intern draait, toch is het antwoord sneller terug vanuit KPN dan vanuit Technitium of Unbound. Ik gebruik de optie voor parallelle requests, de snelste wint.
:strip_exif()/f/image/Xwg7lXJBGsRuJemNd5MIiJNY.png?f=user_large)
:strip_exif()/f/image/C7iHcr12ISQSdgAvPiFtuVqk.png?f=user_large)
Ik heb nog een overlay website gemaakt die de API output van AGH parsed, ik wil beter zien of iets uit cache komt. Draait in een klein docker container.
:strip_exif()/f/image/X7gbwySauciaWJ2QyvoZi6vb.png?f=user_large)
Alle ultrakorte TTL's zet ik op 5 minuten ipv bijvoorbeeld 30seconden.
:strip_exif()/f/image/l6dJvQ9Ljz0BFjWj7aL9E0Vj.png?f=user_large)
In Technitium heb ik de waardes iets verlaagd om prefetching iets eerder af te dwingen.
:strip_exif()/f/image/CYwxVEx0o3GppMFLxXqvi3Ls.png?f=user_large)
Serve stale wait time naar 0
:strip_exif()/f/image/0uI4xlpoQ5xaIdhUQmdcEFcX.png?f=user_large)
Unbound heb ik ook veel aan getuned voor een 4 core machine hieronder mijn config. Unbound gecompiled met libevent:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
| root@dnsserver:~# cat /etc/unbound/unbound.conf.d/unbound.conf
# Core Server Configuration
server:
# Logging Settings
log-time-ascii: yes
log-time-iso: yes
chroot: ""
logfile: /var/log/unbound.log
verbosity: 0
statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yes
# Server Resource Settings
num-threads: 4
num-queries-per-thread: 4096
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
# Network Interface Configuration
interface: 127.0.0.1
interface: ::1
port: 5335
# Protocol Support
prefer-ip6: yes
incoming-num-tcp: 1024
outgoing-range: 8192
edns-buffer-size: 1232
max-udp-size: 1232
# Cache Configuration
rrset-cache-size: 256m
msg-cache-size: 128m
cache-max-ttl: 86400
cache-max-negative-ttl: 60
# Cache Performance Tuning
prefetch: yes
prefetch-key: yes
serve-expired: yes
serve-expired-ttl: 86400
serve-expired-ttl-reset: yes
serve-expired-reply-ttl: 30
rrset-roundrobin: yes
# Cache Slabs (Concurrency)
msg-cache-slabs: 4
key-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
# Privacy and Security
use-caps-for-id: no
# DNSSEC Configuration
harden-algo-downgrade: no
harden-referral-path: no
# Query Privacy
# Infrastructure Cache Settings
infra-cache-numhosts: 10000
infra-host-ttl: 900
# TLS Configuration
tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
# Root Server Settings
root-hints: "/var/lib/unbound/root.hints"
target-fetch-policy: "3 2 1 0 0"
unwanted-reply-threshold: 10000000
# Private Network Definitions
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 192.0.2.0/24
private-address: 198.51.100.0/24
private-address: 203.0.113.0/24
private-address: 255.255.255.255/32
private-address: fd00::/8
private-address: fe80::/10
private-address: 2001:db8::/32
# Access Control Lists
access-control: 10.0.0.0/8 allow
access-control: 172.16.0.0/12 allow
access-control: 192.168.0.0/16 allow
access-control: 127.0.0.1/32 allow
access-control: ::1/128 allow
access-control: ::/0 refuse |
Ja ik wel, je mag mij bijzonder noemen ;-) op een Ziggo lijn met 18ms zal je het mogelijk niet merken. Op een glasvezel lijn met lage latency, nieuwe UniFi netwerk apparatuur met hardware offloading, WiFi 6E, nieuwe MacBook. Dan kan je de zwakste schakel detecteren, en dat is dan DNS, Vooral als hij bij de root e.a. moet opvragen, ik merk dat direct. Ik kreeg unbound niet snel genoeg naar mijn wensen en dat blijkt ook uit de metingen.
Dit was mijn laatste post erover hoor
het doel is behaald, nu weer van de zonnige dagen genieten met de kids in de kids vakantie.Members only:
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
Ik vind het wel een interessante discussie hoor. Ik heb AGH rechtstreeks op m'n OPNsense router draaien. Clients gaan naar AGH en in AGH is de enige upstream de Unbound van OPNsense zelf.
Voorheen had ik in Unbound altijd 1.1.1.1 en 8.8.8.8 maar ben onlangs geswitched naar Europese servers en ook gelijk over DoT: ThinkPad in "Zelfbouw project: Firewall / Router / AP"
Ik zie in de AGH logs dat queries die uit de AGH cache komen in 1-3ms beantwoord worden, prima. Maar ik zie ook 115-325-417ms en dat is dan in vergelijking met jouw logs en die van @lolgast bijv. wel érg traag. Ik zie zelfs 6000 - 10.000ms, daar gaat wat mis met een te trage upstream DoT resolver denk ik
Heb die DoT servers nu in Unbound geconfigureerd, zal ze eens rechstreeks in AGH zetten zodat ik kan zien welke er zo traag is en die eruit mikken.
Een ping in SmokePing naar de geconfigureerde DoT servers ziet er gewoon rustig uit, 8-24ms.
Voorheen had ik in Unbound altijd 1.1.1.1 en 8.8.8.8 maar ben onlangs geswitched naar Europese servers en ook gelijk over DoT: ThinkPad in "Zelfbouw project: Firewall / Router / AP"
Ik zie in de AGH logs dat queries die uit de AGH cache komen in 1-3ms beantwoord worden, prima. Maar ik zie ook 115-325-417ms en dat is dan in vergelijking met jouw logs en die van @lolgast bijv. wel érg traag. Ik zie zelfs 6000 - 10.000ms, daar gaat wat mis met een te trage upstream DoT resolver denk ik
Heb die DoT servers nu in Unbound geconfigureerd, zal ze eens rechstreeks in AGH zetten zodat ik kan zien welke er zo traag is en die eruit mikken.
Een ping in SmokePing naar de geconfigureerde DoT servers ziet er gewoon rustig uit, 8-24ms.
[ Voor 17% gewijzigd door ThinkPad op 29-04-2025 10:54 ]
Ik heb een aantal van die EU servers in smokeping staan, die zijn niet allemaal even snel. Als je niet de optie voor parallele requests hebt ingeschakeld kiest AGH zelf de snelste en meest betrouwbare via een gewogen algoritme. Maar inderdaad dan moeten ze wel allemaal in AGH staan. AGH is de meest intelligente tool qua logica om keuzes te maken. En je slaat een hop over, omdat je vanuit AGH prima deze EU DNS servers kan aanspreken.:
Ik vind het wel een interessante discussie hoor. Ik heb AGH rechtstreeks op m'n OPNsense router draaien. Clients gaan naar AGH en in AGH is de enige upstream de Unbound van OPNsense zelf.
Voorheen had ik in Unbound altijd 1.1.1.1 en 8.8.8.8 maar ben onlangs geswitched naar Europese servers en ook gelijk over DoT: ThinkPad in "Zelfbouw project: Firewall / Router / AP"
Ik zie in de AGH logs dat queries die uit de AGH cache komen in 1-3ms beantwoord worden, prima. Maar ik zie ook 115-325-417ms en dat is dan in vergelijking met jouw logs en die van @lolgast bijv. wel érg traag. Ik zie zelfs 6000 - 10.000ms, daar gaat wat mis met een te trage upstream DoT resolver denk ik
Heb die DoT servers nu in Unbound geconfigureerd, zal ze eens rechstreeks in AGH zetten zodat ik kan zien welke er zo traag is en die eruit mikken.
Een ping in SmokePing naar de geconfigureerde DoT servers ziet er gewoon rustig uit, 8-24ms.
Wist je dat UniFi bij de WAN instellingen voor DNS op "auto" ook 1.1.1.1 aanroept naast de DNS van je provider? Daarmee kan je stellen dat 1.1.1.1 ook een hele goede cache vullingsgraad heeft. Bij een EU DNS server denk ik dat de cache minder optimaal is voor Hollands gebruik, ik hoor er niet veel mensen over.
:strip_exif()/f/image/zZxtIUG3V3CWGoZbYhOM7Jyb.png?f=user_large)
[ Voor 11% gewijzigd door stormfly op 29-04-2025 20:27 ]
:strip_icc():strip_exif()/u/16677/crop5db01361a1e1e_cropped.jpeg?f=community)
Asustor AS6704T (32GB, 4x16TB MG08), OpenWrt (3x GL.iNet Flint 2 MT6000), Lyrion Media Server, Odroid H2/N2+/C4/C2, DS918+ (4x8TB WD RED)
Ik geen, want ze staan voor mij allemaal op een te grote afstand. Heb er wel een aantal in smokeping staan, je ziet ze op het screenshot met hun IP's
Het gaat mij om de cache hit ratio, anderen gaat het om privacy. Voor de cache is mijn theorie als volgt: ik hoor veel mensen om mij heen (Nederland) het hebben over 8.8.8.8 of 1.1.1.1 of 9.9.9.9. Als ik een EU DNS server gebruik dan kan die DNS server prima het Luxemburgse NU.lux in cache hebben maar als ik AD.nl bezoek moet hij een lange lookup doen omdat hij minder vaak lijkt gebruikt te zijn in onze omgeving. Wat deze DNS server voor mij trager maakt. Ook zijn er een aantal wel goed bereikbaar met een lage ping, anderen een fors hoge ping 40-100ms. Qua privacy ->is 8.8.8.8 voor mij wel een brug te ver omdat het bekend is dat Google leeft van data.
Bij controlD zie je dat gedrag goed, het is overigens iets gezakt. Een paar werken terug zaten ze op 5ms ping en 10ms resolve tijd. Waarbij ze een heel goed peering (internet) netwerk hebben, alleen zijn hun servers flink traag. Omdat ik graag met netwerken knutsel is RTT voor mij wel een relevante waarde, je hebt helemaal gelijk dat voor deze discussie de DNS REQ de plaat is waar we naar zouden moeten kijken. Het zijn dig probes.
Ik heb controlD eens toegevoegd in AGH +9.9.9.9 naast KPN en mijn eigen Technititum om te kijken hoe de ranking zich uitlijnt, of AGH hetzelfde beeld geeft als smokeping dat controlD vrij/erg traag is ondanks hun leuke nerdy marketing.
:strip_exif()/f/image/dGoqLYY5Eam2CT4aSnmseMWI.png?f=user_large)
Voor GitHub loopt er nog een leercurve hier
ik heb de readme net aangepast. PB mij anders even om het werkend te krijgen, als het nu nog niet doorloopt.offtopic:
EDIT: in de NPO app startte ik een video en dat komt blijkbaar uit lokale caches in het KPN netwerk. Ik weet dat KPN NetFlix caches heeft om zoveel mogelijk verkeer in het netwerk te houden. Dat heeft zich uitgebreid voor NPO. Zou je deze caches ook gebruiken als je 3th party DNS gebruikt?
edge.prd.cdn.bcms.gslb.kpn.com
npo.prd.cdn.bcms.kpn.com
NetFlix cache script
/f/image/9fImhbvPE3xYEf8AjbsL0Rnl.png?f=fotoalbum_large)
EDIT: in de NPO app startte ik een video en dat komt blijkbaar uit lokale caches in het KPN netwerk. Ik weet dat KPN NetFlix caches heeft om zoveel mogelijk verkeer in het netwerk te houden. Dat heeft zich uitgebreid voor NPO. Zou je deze caches ook gebruiken als je 3th party DNS gebruikt?
edge.prd.cdn.bcms.gslb.kpn.com
npo.prd.cdn.bcms.kpn.com
NetFlix cache script
:strip_exif()/f/image/9fImhbvPE3xYEf8AjbsL0Rnl.png?f=user_large)
[ Voor 20% gewijzigd door stormfly op 30-04-2025 09:19 ]
Zover ik begrijp is de rechts response tijd kolom in AGH niet meer dan een simpele ping, want mijn Technitium staat daar op LAN snelheid 1ms maar toch wint KPN het in de linker kolom in het vele aantal replies die hij als eerste beantwoord.
Mijn DoT test zou zijn: allemaal invullen als upstream, parallelle verzoeken naar servers vinkje inschakelen en dan de linkse kolom uitlezen over 24 hr.
:strip_exif()/f/image/KUoPS9zpmqR0ltAwJtWQwdVU.png?f=user_large)
:strip_exif()/f/image/oL4DkPak1Llc183SkdGTuSQV.png?f=user_large)
Hij heeft ook een tijdje buiten Amsterdam gedraaid
Ik heb niets te verbergen, waarom willen gebruikers persé anoniem blijven? Als er om wat voor reden een onderzoek komt dan zet de ISP een internettap op de POP en tappen ze gewoon je fiberdata af en sturen ze een tcpdump file door naar de overheid. Het gaat jullie over de UDP pakketten die door andere ISP's gaan en in plaintext te lezen zijn als je ze onderschept?
Nee DoT heeft TCP als overhead, dat moet opbouwen met een 3way handshake mij te traag
waar ik wel naar uitkijk is DoH/3 of native QUIC. DoH/3 over HTTPv3 dat is UDP QUIC gebaseerd zonder TCP. Dat is alleen nog niet heel breed beschikbaar, beide zijn zeldzaam ondersteund.Voor nu is 9.9.9.9 heel erg snel, leuke support en goede visie met die embedded security blocks. Alleen hebben ze ontzettend vaak last van DDOS attacks en dat ligt de boel plat, je moet er dus iets naast hebben voor 9.9.9.9. Voor mij zou dat dan 1.1.1.1 zijn als je niets van je provider wilt gebruiken, beide hebben ook DoT.
Ik ben benieuwd of jij na je DoT testen, ook eens kan testen met 2x Odido en 9.9.9.9 en 1.1.1.1 en dan het vinkje parallelle verzoeken ingeschakeld. Hoe vult de linkse kolom zich, hoe snel is de Odido DNS farm tov 9.9.9.9?
Ik zal de test nog eens opnieuw doen dan, de tabel die ik hierboven postte was alleen de rechterkolom.
Het gaat mij niet zozeer om anoniem blijven, maar meer dat ik met een vrij simpele ingreep kan zorgen dat niet alles klakkeloos unencrypted richting de VS gaat (1.1.1.1 en 8.8.8.8). Gaat idd ten koste van wat snelheid, maar ik moet zeggen dat het mij met browsen niet eens echt is opgevallen. Kwestie van in het interne netwerk zoveel mogelijk een goede cache opbouwen.
Ik kon zo 123 alleen DNS4ALL.eu vinden die QUIC ondersteunt. Maar die is nog vrij experimenteel en zelfs via QUIC nog behoorlijk traag. Maar ik keek ook naar de verkeerde kolom dus zal dat nog eens opnieuw beoordelen. Lees her-en-der wel wat over Quad9 die QUIC wil gaan ondersteunen, maar een roadmap is nog niet bekend.:
Nee DoT heeft TCP als overhead, dat moet opbouwen met een 3way handshake mij te traag
Het 'advies' was altijd om niet de DNS van je ISP te gebruiken want die waren vaak maar slecht, vaak storing etc. Ben daar de laatste jaren wel op teruggekomen. Het is een resolver die het dichtste bij je zit. Als je een goede interne resolver hebt die meerdere servers kan raadplegen en niet eerst gaat zitten wachten op een ISP DNS die misschien traag reageert dan is het volgens mij dikke prima. Ja het is unencrypted, maar het is alleen de ISP zelf die kan meelezen.
En als ze het DNS verkeer niet kunnen meelezen, dan zie ze alsnog wel welke webserver e.d. je contacteert.
Weer 24u verder, dit is de score.
:no_upscale():strip_icc():strip_exif()/f/image/8uVFxelgwQB3Hy0adpV3NEI0.jpg?f=user_large)
De primary van Odido gaat dus het meeste heen. Die is qua snelheid ook dikke prima. De secondary (62.58.48.20) is echt langzaam, met een simpele ping vanaf de router zie ik dat ook al (11ms vs 7ms voor de primary). Staat toch wat verder weg in het netwerk blijkbaar. Dit zijn overigens de DNS die ik op WAN DHCP kreeg. Ik zie hier weer anderen: https://www.odido.nl/serv...ido-dns-servers/000454242 maar die reageren niet op een dig. Misschien zijn ze voor DSL infra.
Ik ga 9.9.9.10 (Quad9 unfiltered) ook nog even toevoegen, die was naar mijn herinnering sneller dan de reguliere (filtered) Quad9. En heb de filtering toch liever zelf in de hand (via AGH) zodat ik evt. false positives kan corrigeren.
[ Voor 3% gewijzigd door ThinkPad op 01-05-2025 21:48 ]
Tnx voor je uitgebreide reactie! Inderdaad 1.1.1.1 is ook van de Amerikanen, dan is een ISP DNS op dit moment in deze wereldpolitiek zo gek nog niet.
Cool om te zien dat Odido toch ook tenminste één snelle DNS server heeft. KPN heeft naar haar DNS 3-4ms ping. 9.9.9.9 filtert alleen security, dan nog ben ik met je eens dat je de filtering zelf zou willen controleren.
Ik heb nog een oude mail opgezocht van 9.9.9.9 waar ze wat meer uitleg geven. Ik was zelf altijd helemaal fan van de .11 waarbij je dan een hash/deel van je IP blootgeeft om daarvoor in ruil het dichtstbijzijnde CDN toegewezen te krijgen. Dat zit toch iets anders in elkaar.
Overigens heeft 9.9.9.10 geen DNSSEC waardoor hij mogelijk wat sneller is in jouw ervaring.
Members only:
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
EDIT:
:strip_exif()/f/image/aT35LiO6qSTMwUVKZSZmhnEs.png?f=user_large)
Geen noemenswaardige verschillen tussen .9 .10 je ziet dat de .11 wat trager is zoals het mailtje van Quad9 ook suggereert.
[ Voor 7% gewijzigd door stormfly op 01-05-2025 21:47 ]
:strip_icc():strip_exif()/u/232052/avatar.jpg?f=community){kind=avatar}
:strip_exif()/u/45096/Jumpman.gif?f=community)
Asustor AS6704T (32GB, 4x16TB MG08), OpenWrt (3x GL.iNet Flint 2 MT6000), Lyrion Media Server, Odroid H2/N2+/C4/C2, DS918+ (4x8TB WD RED)