Начиная примерно с вечера 26 августа, на ТСПУ стали перехватывать открытые DNS запросы к крупным DNS серверам CloudFlare и Google (1.1.1.1, 8.8.8.8), ранее блокировали DoH сервера от данных корпораций.

Результат DNS резолвинга выглядит следующим образом:

~# dig youtube.com @8.8.8.8

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> youtube.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59147
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 9 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Thu Aug 27 13:37:35 MSK 2026
;; MSG SIZE  rcvd: 40

~# dig rutracker.org @1.1.1.1

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> rutracker.org @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23001
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 9 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Thu Aug 27 13:37:20 MSK 2026
;; MSG SIZE  rcvd: 42

Но как это работает на самом деле, с технической точки зрения? Если посмотреть tcpdump, то возвращается сразу NXDomain:

~# tcpdump -n -i ppp0 host 8.8.8.8
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
13:40:30.834385 IP X.X.X.X.60791 > 8.8.8.8.53: 63359+ [1au] A? youtube.com. (52)
13:40:30.845588 IP 8.8.8.8.53 > X.X.X.X.60791: 63359 NXDomain* 0/0/1 (40)

Однако перехват работает только для UDP протокола, по TCP возвращаются настоящие IP-адреса:

~# dig +tcp youtube.com @8.8.8.8

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> +tcp youtube.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48032
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;youtube.com.			IN	A

;; ANSWER SECTION:
youtube.com.		300	IN	A	64.233.162.136
youtube.com.		300	IN	A	64.233.162.91
youtube.com.		300	IN	A	64.233.162.93
youtube.com.		300	IN	A	64.233.162.190

;; Query time: 33 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (TCP)
;; WHEN: Thu Aug 27 13:41:55 MSK 2026
;; MSG SIZE  rcvd: 104

И тут в ходе экспериментов, возникает следующая интересная ситуация, если отправить запрос резолвинга A записи сначала с ttl 2 (отправка до узла после ТСПУ), а затем повторить отправку, но уже с ttl 64, то тогда возвращается оригинальный ответ:

~# tcpdump -n -i ppp0 host 8.8.8.8 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
11:48:27.486777 IP (tos 0x0, ttl 2, id 154, offset 0, flags [none], proto UDP (17), length 82)
    X.X.X.X.23121 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
11:48:30.533401 IP (tos 0x0, ttl 64, id 11794, offset 0, flags [none], proto UDP (17), length 82)
    X.X.X.X.23121 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
11:48:30.683231 IP (tos 0x0, ttl 109, id 1909, offset 0, flags [none], proto UDP (17), length 102)
    8.8.8.8.53 > X.X.X.X.23121: 35076 2/0/1 rutracker.org. A 172.67.182.196, rutracker.org. A 104.21.32.39 (74)

При этом отправка рандомного пакета (не DNS запроса) с ttl 2 в начале не изменяет ситуацию, и при повторной отправке с ttl 64 будет получен NXDomain:

~# tcpdump -n -i ppp0 host 8.8.8.8 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
11:54:00.766581 IP (tos 0x0, ttl 2, id 3798, offset 0, flags [none], proto UDP (17), length 380)
    X.X.X.X.21631 > 8.8.8.8.53: 20150 updateA Resp11*-| [46423q] [|domain]
11:54:00.899956 IP (tos 0x0, ttl 64, id 22135, offset 0, flags [none], proto UDP (17), length 82)
    X.X.X.X.21631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
11:54:00.911030 IP (tos 0x0, ttl 60, id 9107, offset 0, flags [none], proto UDP (17), length 70)
    8.8.8.8.53 > X.X.X.X.21631: 35076 NXDomain* 0/0/1 (42)

В моём случае, отправляя запросы прямо с маршрутизатора, перехват DNS начинается только с ttl 5:

~# tcpdump -n -i ppp0 host 8.8.8.8 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
12:10:08.061153 IP (tos 0x0, ttl 5, id 33938, offset 0, flags [none], proto UDP (17), length 82)
    X.X.X.X.34240 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
12:10:08.080281 IP (tos 0x0, ttl 60, id 31520, offset 0, flags [none], proto UDP (17), length 70)
    8.8.8.8.53 > X.X.X.X.34240: 35076 NXDomain* 0/0/1 (42)

И тут самое интересное, если выслать DNS запрос с TTL 2 до 8.8.8.8, тогда в ICMP TTL Exceeded будет содержаться dst ip не 8.8.8.8, а 195.208.5.1 (сервер НСДИ):

Dst адрес был подменён со стороны ТСПУ

Подмена dst адреса происходит только в том случае, если в пакете содержится DNS запрос, у пакетов с рандомным содержимым dst адрес не модифицируется. Получается следующая картина:

Наглядная схема, как это работает

При очень быстрой отправке DNS запросов в рамках одного соединения получается очень интересный сбой, сначала отдаёт NXDomain, а затем настоящие IP-адреса:

~# tcpdump -n -i ppp0 host 8.8.8.8 
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
11:58:27.180858 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
11:58:27.181146 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
11:58:27.181300 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
11:58:27.181424 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
11:58:27.181540 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
11:58:27.199977 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 NXDomain* 0/0/1 (42)
11:58:27.213332 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 2/0/1 A 104.21.32.39, A 172.67.182.196 (74)
11:58:27.213482 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 2/0/1 A 172.67.182.196, A 104.21.32.39 (74)
11:58:27.213542 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 2/0/1 A 104.21.32.39, A 172.67.182.196 (74)
11:58:27.216791 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 2/0/1 A 172.67.182.196, A 104.21.32.39 (74)

Вывод: ТСПУ осуществляет направленный DNAT в сторону НСДИ при наличии DNS протокола внутри пакета, а так же при определённых dst адресах (не на всех DNS серверах происходит DNAT). Оператор связи на выходе после ТСПУ видит не dst адрес 8.8.8.8, а адрес НСДИ (195.208.5.1). С точки зрения оператора связи, трафик к 8.8.8.8 по netflow статистике должен был упасть.

Проголосовали 218 пользователей. Воздержались 137 пользователей.