Waarom DNS-controles falen vanuit Rusland, China en Taiwan (en hoe we het hebben opgelost)
Soms faalt een DNS-controle niet vanwege iets fout met DNS zelf. Ze faalt omdat het netwerkpad naar de resolver geblokkeerd is voordat de query ooit vertrekt — en geen hoeveelheid opnieuw proberen of resolvers wisselen verandert daar iets aan.
Het probleem dat we vonden
Testen rechtstreeks vanaf de productiehost, niet alleen in theorie, toonde aan dat het netwerk ervan poort 53 (zowel UDP als TCP), DoH en DoT volledig blokkeert naar resolvers in Rusland, China en Taiwan.
De omvang ervan
40 resolvers waren getroffen — Yandex, 114DNS, AliDNS, Baidu, HiNet, Quad101, Rostelecom, MSK-IX en meer liepen allemaal vast op een time-out. Alleen DNSPod en KT reageerden rechtstreeks.
Waarom een andere resolverlijst dit niet kon oplossen
Dit is geen kwestie van welke resolvers over het algemeen betrouwbaar zijn — het is het eigen netwerkpad van de host naar specifieke landen dat geblokkeerd is op een niveau dat geen enkele resolver-whitelist kan bereiken. Wisselen welke resolvers worden bevraagd verandert niets wanneer de verbinding zelf nooit vertrekt.
De daadwerkelijke oplossing
Een Cloudflare Worker (app/probe-worker) herhaalt de DNS-query via TCP/53 vanuit het eigen netwerk van Cloudflare, dat niet aan dezelfde blokkade onderhevig is, en stuurt het ruwe antwoord terug naar onze backend.
Welke resolvers via de relay lopen
Zeven specifieke resolvers worden zo geleid — Yandex, 114DNS (twee adressen), AliDNS (twee adressen) en HiNet — via queryViaProbe in probe.go, en alleen wanneer de omgevingsvariabelen PROBE_URL en PROBE_TOKEN daadwerkelijk zijn ingesteld. Zonder deze verandert er niets; elke andere resolver wordt precies zoals voorheen bevraagd.
Waarom dit geen open proxy is
De Worker vereist een bearer-token en accepteert alleen query's voor die vaste lijst van zeven resolvers — hij kan niet worden gebruikt om willekeurig DNS-verkeer ergens anders naartoe door te sturen.
De grenzen van het gratis plan die het ontwerp vormgeven
Het gratis Workers-plan van Cloudflare staat 100.000 verzoeken per dag toe, 10 ms CPU-tijd, 50 subverzoeken en 6 gelijktijdige verbindingen per aanroep — wat neerkomt op ongeveer 3.500 controles per dag bij 28 Worker-aanroepen elk.
Probeer een propagatiecontrole
Zie de theorie in de praktijk — voer DNS-propagatiechecker uit voor je eigen domein.