Perché i controlli DNS falliscono da Russia, Cina e Taiwan (e come lo abbiamo risolto)

Il problema che abbiamo trovato

Testando direttamente dall'host di produzione, non solo in teoria, è emerso che la sua rete blocca completamente la porta 53 (sia UDP che TCP), DoH e DoT verso i resolver in Russia, Cina e Taiwan.

L'entità del problema

Erano coinvolti 40 resolver — Yandex, 114DNS, AliDNS, Baidu, HiNet, Quad101, Rostelecom, MSK-IX e altri andavano tutti in timeout. Solo DNSPod e KT rispondevano direttamente.

Perché una lista di resolver diversa non poteva risolverlo

Non è una questione di quali resolver siano affidabili in generale — è il percorso di rete proprio dell'host verso paesi specifici a essere bloccato a un livello che nessuna whitelist di resolver può raggiungere. Cambiare quali resolver vengono interrogati non cambia nulla quando la connessione stessa non parte mai.

La soluzione reale

Un Cloudflare Worker (app/probe-worker) ripete la query DNS via TCP/53 dalla rete stessa di Cloudflare, che non è soggetta allo stesso blocco, e restituisce la risposta grezza al nostro backend.

Quali resolver passano attraverso il relay

Sette resolver specifici vengono instradati così — Yandex, 114DNS (due indirizzi), AliDNS (due indirizzi) e HiNet — tramite queryViaProbe in probe.go, e solo quando le variabili d'ambiente PROBE_URL e PROBE_TOKEN sono effettivamente configurate. Senza di esse, nulla cambia; ogni altro resolver viene interrogato esattamente come prima.

Perché questo non è un proxy aperto

Il Worker richiede un token bearer e accetta solo query per quella lista fissa di sette resolver — non può essere usato per inoltrare traffico DNS arbitrario altrove.

I limiti del piano gratuito che modellano il design

Il piano gratuito Workers di Cloudflare consente 100.000 richieste al giorno, 10 ms di tempo CPU, 50 sotto-richieste e 6 connessioni simultanee per invocazione — il che equivale a circa 3.500 controlli al giorno con 28 chiamate al Worker ciascuno.

Prova un controllo di propagazione