DNS over TLS su Fritz di opendns

dfrincon

ho aggiunto al fritz questo dns
dns.opendns.com
ma non viene usato è normale
invece sul telefono android funziona
ultimo fimware 7.57
come mai qualcuno lo sa?

Cal

dfrincon ma non viene usato

in che senso? che dns viene usato?

ti sei disconnesso/riconnesso dopo che hai cambiato quest'impostazione?

sursumcorda

dfrincon ho aggiunto al fritz questo dns
dns.opendns.com
ma non viene usato è normale
invece sul telefono android funziona
ultimo fimware 7.57
come mai qualcuno lo sa?

Per capirci, hai inserito i relativi IP sotto Server DNSv4?

dfrincon

viene usato quello dell operatore
connesso e disconnesso ma non lo vede e non lo usa

dfrincon

no o messo dns.opendns.com su DNS over TLS (DoT)
altri dns tipo google tls vanno

Cal

dfrincon e hai motivi specifici per usare opendns?

(lo sai che quelli più veloci sono quasi sempre quelli di cloudflare, no?)

dfrincon

che siano i + veloci sempre non credo
il punto è perché opendns non va e gli altri si?
se uso quelli normali vanno invece i DoT no
è un bug del fritz? sugli eventi non vedo niente
sto usando un 7530

[cancellato]

dfrincon

Perché non sono quelli che devi usare: https://support.opendns.com/hc/en-us/articles/360038086532-Using-DNS-over-HTTPS-DoH-with-OpenDNS - devi usare doh.opendns.com

Cal

dfrincon che siano i + veloci sempre non credo

Sempre magari no, ma ti tocca provare per vedere quali vanno meglio dalla tua posizione. È improbabile che i migliori siano opendns.

Parnas

[cancellato] Perché non sono quelli che devi usare: https://support.opendns.com/hc/en-us/articles/360038086532-Using-DNS-over-HTTPS-DoH-with-OpenDNS - devi usare doh.opendns.com

Il fritz-box supporta solo DoT (DNS over TLS), non puoi impostare un DoH.

[cancellato]

Parnas

Allora non credo che OpenDNS lo supporti - certe stranezze nelle implementazioni di AVM non le capisco.... se hai fatto 30, fai 31.

Cal

La velocità della risoluzione DNS è irrilevante da quando quasi tutti i client e i forwarder cachano i valori per un tempo piuttosto lungo. È rilevante solo per i client che non fanno cache.

Cal

[cancellato] insomma.

Per fortuna queste cache non sono così lunghe. E non so quante query ti tocca fare alla prima apertura di un sito.

Dal mio PoV stiamo parlando di 34 ms da 1.1.1.1 e 21 ms da cache locale. Quasi 200 ms se installo un recursive resolver in locale. (incluso l'overhead di dig e della shell).

dfrincon

comunque ho trovato la soluzione bisogna disabilitare

Forzare un controllo del certificato per la risoluzione crittografata dei nomi in Internet
Consentire solo server la cui completa convalida ha esito positivo.
L'impostazione dovrebbe essere disattivata solo se si conosce l'identità del server.

cosi opendns funziona

handymenny

Cal e 21 ms da cache locale

ma questa cache dove è e come ci accedi?

io ho questi risultati con una semplice query A:
< 1ms cache dispositivo
< 8ms (media 3ms) cache lan primo livello (dnsmasq su router)
< 8 ms (media 3ms) cache lan secondo livello (adguardhome)
Sulla lan uso il normale DNS via udp e ho anche io incluso l'overhead di dig

[cancellato]

Cal Per fortuna queste cache non sono così lunghe.

Dipende dal valore di TTL nella risposta DNS - dipende quindi da che valore è stato impostato per un determinato host. Poi dipende da che valore il client o il forwarder DNS impone come massimo per la cache (per Windows di default è 1 giorno per i record risolti positivamente). Il problema credo fosse che Linux pre-systemd al contrario di Windows di default non faceva cache lato client - comunque molti forwarder, inclusi ormai quelli sui router, di solito lo fanno.

Poi se usi NoScript certi siti si caricano molto, molto più velocemente <G>.

Cal

handymenny è un po' lontana, dnscrypt-proxy che gira per i fatti suoi su Windows, query da dentro wsl (che avrà la sua cache a sua volta). C'è una marea di overhead. Come li hai misurati quei tempi?

handymenny

Cal "dig fibra.click" da un device nella lan (cablato)

Cal

handymenny sono un idiota, andavo di time dig @... fibra.click invece di leggere "Query time: 0 msec" nel suo output.

Sono 9-10 ms da dnscrypt-proxy, 0 da cache locale (dnscrypt probabilmente), e 190 da resolver autonomo.

% docker run -d -p 127.53.53.1:53:53/udp docker.io/mvance/unbound
a7ede5b6d2a4e9aa9140a0099764ca2981a7318f13e6acf4206b62ce38a158d7
% time dig @127.53.53.1 a fibra.click

; <<>> DiG 9.18.16-1-Debian <<>> @127.53.53.1 a fibra.click
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13876
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fibra.click.                   IN      A

;; ANSWER SECTION:
fibra.click.            300     IN      A       104.26.13.214
fibra.click.            300     IN      A       104.26.12.214
fibra.click.            300     IN      A       172.67.70.141

;; Query time: 190 msec
;; SERVER: 127.53.53.1#53(127.53.53.1) (UDP)
;; WHEN: Mon Sep 11 07:46:05 CEST 2023
;; MSG SIZE  rcvd: 88

dig @127.53.53.1 a fibra.click  0.00s user 0.04s system 11% cpu 0.319 total

Cal

[cancellato] il TTL nel resource record è un mero suggerimento, però sì, normalmente dovrebbe funzionare in quel modo.

Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈 🇵🇸
P.I. IT16712091004 - info@fibraclick.it

♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile