edofullo Sto parlando con cognizione di causa, ho provato tempo fa direttamente diversi server DNS da una linea PF e soltanto Google e Cloudflare rispondevano mentre gli altri (OpenDNS, Quad9, non ricordo se HE o L3) andavano tutti in timeout (in IPv4).
E infatti qui (e solo qui, in grassetto) confermi quello che ho detto anche io, e che e' ancora cosi' in quanto l'ho provato ieri prima di scrivere il mio post. I pacchetti che entrano dal transito incriminato e che non sono in whitelist, vengono droppati, per evidenti motivi di antiflood.
Il mio "Non spargiamo disinformazione a caso, grazie!" e' pero' ovviamente chiaramente riferito al tuo bel "magari" in grassetto visto che tale tua ipotesi e' completamente infondata e non rispondente al vero, e quindi confermo, sottolineo e reitero il mio invito a non spargere disinformazione a caso, grazie!
Ripeto, in grassetto: Nessun redirect, nessuna intercettazione (che sarebbero gravissimi), solo un filtro che blocca determinati pacchetti in entrata, con motivazione anti-DDoS che ben si conosce.
edofullo Questo in entrata è fuorviante. Intendi che viene bloccata la risposta? Perchè si parla di query "in uscita" e non frega nulla a nessuno di query "in entrata" (verso un server DNS in LAN)
Perche' mai dovrebbe essere fuorviante? Ho descritto correttamente quello che accade (in grassetto), ossia, i pacchetti in uscita destinati alla 53/udp non vengono bloccati, e arrivano alla destinazione, vengono pero' bloccati i pacchetti in entrata provenienti dalla 53/udp ed entranti da un dato transito. Quindi si', "viene bloccata la risposta", se vuoi dirlo cosi'. Ma la "risposta" e' pur sempre un pacchetto in entrata... E ai router stateless come quelli nelle reti degli ISP frega nulla se un pacchetto fa parte di una connessione (anzi conntrack entry, va, che stiamo parlando di UDP), o di chi ha inviato il "primo pacchetto", e men che mai del contenuto del pacchetto.
/fin 🤔
