Dlaczego sprawdzanie DNS zawodzi z Rosji, Chin i Tajwanu (i jak to naprawiliśmy)

Problem, który znaleźliśmy

Testowanie bezpośrednio z hosta produkcyjnego, nie tylko teoretycznie, pokazało, że jego sieć całkowicie blokuje port 53 (zarówno UDP, jak i TCP), DoH i DoT do resolverów w Rosji, Chinach i na Tajwanie.

Skala problemu

Dotknęło to 40 resolverów — Yandex, 114DNS, AliDNS, Baidu, HiNet, Quad101, Rostelecom, MSK-IX i inne, wszystkie przekraczały limit czasu. Tylko DNSPod i KT odpowiadały bezpośrednio.

Dlaczego inna lista resolverów tego nie naprawiła

To nie jest kwestia tego, które resolvery są ogólnie niezawodne — to własna trasa sieciowa hosta do konkretnych krajów jest zablokowana na poziomie, do którego żadna biała lista resolverów nie sięga. Zmiana odpytywanych resolverów niczego nie zmienia, gdy samo połączenie nigdy nie wychodzi.

Rzeczywista naprawa

Cloudflare Worker (app/probe-worker) powtarza zapytanie DNS przez TCP/53 z własnej sieci Cloudflare, która nie podlega tej samej blokadzie, i zwraca surową odpowiedź z powrotem do naszego backendu.

Które resolvery przechodzą przez przekaźnik

W ten sposób kierowanych jest siedem konkretnych resolverów — Yandex, 114DNS (dwa adresy), AliDNS (dwa adresy) i HiNet — przez queryViaProbe w probe.go, i tylko wtedy, gdy zmienne środowiskowe PROBE_URL i PROBE_TOKEN są faktycznie skonfigurowane. Bez nich nic się nie zmienia; każdy inny resolver jest odpytywany dokładnie tak jak wcześniej.

Dlaczego to nie jest otwarte proxy

Worker wymaga tokenu bearer i akceptuje zapytania tylko dla tej stałej listy siedmiu resolverów — nie można go użyć do przekazywania dowolnego ruchu DNS gdziekolwiek indziej.

Limity darmowego planu, które kształtują ten projekt

Darmowy plan Cloudflare Workers pozwala na 100 000 żądań dziennie, 10 ms czasu CPU, 50 podzapytań i 6 jednoczesnych połączeń na wywołanie — co daje w przybliżeniu 3500 sprawdzeń dziennie przy 28 wywołaniach Workera na każde.

Wypróbuj sprawdzenie propagacji