На ТСПУ начали перехватывать открытые DNS запросы к 1.1.1.1, 8.8.8.8 / Хабр

Начиная примерно с вечера 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 адреса происходит только в том случае, если в пакете содержится 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 статистике должен был упасть.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

81.25%Да78

18.75%Нет18

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

Как я, учась в айти, работаю на 15-тонном советском станке и автоматизирую его без CAM‑системы и комментариев

Мне 19. Днем я очный студент айтишник, а в остальное время — единственный человек в цеху, кто работает на 15-тонном советском горизонтально‑фрезерном станке ИР-500. Мозги у этого монстра под стать эпохе: древняя корейская стойка Fanuc 0-M 1982 года.

Сам ИР-500 — настоящий танк. По оси Z ездит сразу вся огромная чугунная коробка на рельсах.. А когда эта масса разгоняется, пол вибрирует, но сам станок стоит намертво. Он воспринимает дикие нагрузки на минимальных оборотах — как легкую прогулку.

Но есть проблема, передачу файлов через кабель он не поддерживает, CAM‑систему не подключить..
Для меня, привыкшего к созданию 3D‑моделей и визуализации всех траекторий в Fusion360 — было непросто адаптироваться.

Мои первые самостоятельные дни были очень болезненными, хотелось просто уволиться, ведь малейшая ошибка и невнимательность здесь — это не упавший сервер, а разнесенная фреза и тиски. Поэтому каждый первый запуск новой программы — это паранойя. Рука на остановке подачи, покадровый режим, минимальные перемещения и подача. И только когда фреза пускала стружку, я выдыхал и выкручивал подачу на максимум.

Пока детали требовали обработки в пару проходов, было все отлично. Но потом...

Началось спагетти из g‑кода. Пошли заказы на глубокое торцевание (или более сложные траектории, но сегодня не об этом), где можно потратить пол смены на написание программы.

На ТСПУ начали перехватывать открытые DNS запросы к 1.1.1.1, 8.8.8.8

Как я, учась в айти, работаю на 15-тонном советском станке и автоматизирую его без CAM‑системы и комментариев

Wi-Fi научился видеть людей сквозь стены. Я полез в код, и там нашёлся подвох

410.chat — Одноразовый чат для двоих

Публикации