Если очень сильно захотят, то могут выпустить серт от УЦ минцифры на домен Ютуба, отдавать на DNS серверах НСДИ IP-шник сервера который будет редиректить на рутуб.
Относительно перехвата DNS запросов со стороны операторов связи у меня есть следующие наблюдения:
Эр-телеком: подмены dst адреса нет, при использовании стороннего резолвера используется реально введённый DNS сервер в настройках системы или роутера (это видно по пингу и по всяким различным тестам "DNS утечки"), однако при попытке резолвинга заблокированных доменов по реестру, будет отдаваться IP-адрес заглушки (отдаёт так же только по UDP). Они отдают заглушку даже если резолвить домены извне:
~# dig rutracker.org @188.187.188.255
; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> rutracker.org @188.187.188.255
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21106
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;rutracker.org. IN A
;; ANSWER SECTION:
rutracker.org. 600 IN A 188.186.146.207
;; Query time: 46 msec
;; SERVER: 188.187.188.255#53(188.187.188.255) (UDP)
;; WHEN: Sat Aug 29 12:38:58 MSK 2026
;; MSG SIZE rcvd: 47
При этом реального DNS сервера на 188.187.188.255 - нет
~# dig 2ip.ru @188.187.188.255
;; communications error to 188.187.188.255#53: timed out
(IP-адрес был взят наугад)
Уфанет: подмены ответа при использовании других резолверов нет, но на операторских DNS серверах заблокированные домены по реестру не резолвятся
Ростелеком: на их резолверах отдаётся в ответе 127.0.0.1 при резолвинге фейсбука или инстаграма, с остальными ресурсами по типу рутрекера всё хорошо, при использовании сторонних серверов отдачи заглушки нет
Принцип работы перехвата DNS эр-телекома и ТСПУ значительно отличаются.
Ничего не мешает поднять свой приватный DoH сервер и пользоваться им (если публичные перебанят, или если ГРЧЦ/ЦМУ ССОП начнёт путём сканирования всего интернета искать DoH сервера дёргая GET/POST /dns-query и блокировать их)
А TXT записи резолвятся через восьмёрки в незашифрованном DNS? Если исходящий и входящий трафик проходят через разные ТСПУ, то вряд ли трансляция адресов будет корректно работать в этом случае, ответ придёт далеко не от 8.8.8.8
Могу лишь предположить, что ТСПУ перестаёт делать DNAT после получения ICMP TTL Exceeded:
~# tcpdump -n -i ppp0 host 8.8.8.8 or icmp -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
16:44:44.926651 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:44.934296 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 195.208.5.1.53: [|domain]
16:44:45.928461 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:45.933575 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:46.929807 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:46.932393 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:47.931497 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:47.935700 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:48.933436 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:48.934812 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:49.935547 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:49.937371 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:50.937174 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:50.938080 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:51.938533 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:51.939320 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
Но при резолвинге по несколько раз с TTL 64 в рамках одного соединения отдаёт NXDomain стабильно (за исключением случая кратковременно большого pps/rps, как это описано в статье):
~# 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
16:42:40.789678 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:40.800943 IP (tos 0x0, ttl 60, id 45883, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:41.790464 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:41.801422 IP (tos 0x0, ttl 60, id 45984, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:42.792903 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:42.803986 IP (tos 0x0, ttl 60, id 46022, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:43.794361 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:43.812382 IP (tos 0x0, ttl 60, id 37938, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:44.796254 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:44.807262 IP (tos 0x0, ttl 60, id 46353, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:45.797252 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:45.814865 IP (tos 0x0, ttl 60, id 38123, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:46.799729 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:46.818311 IP (tos 0x0, ttl 60, id 38189, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:47.801971 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:47.819693 IP (tos 0x0, ttl 60, id 38337, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
По пути у меня нет узлов, которые бы не отдавали ICMP TTL Exceeded.
Если учитывать текущую техническую реализацию (а реализовано оно усечённым, легковесным и одновременно странным DNAT), то 443 порт должен уходить на какой-то сторонний прокси сервер в интернете, этот самый прокси должен по SNI отрезолвить домен, в результате чего исходный IP-адрес клиента просто потеряется (если его не добавлять отдельным заголовком конечно), это сломает веб-ресурсы, которые доступны только по белым спискам src адресов.
Если конечно, ТСПУ не научится в полноценный MITM в рамках TLS без потерь IP-адресов, или если провайдер не разместит прокси сервера у себя.
В данном случае ТСПУ не занимается подделкой DNS ответа, он просто меняет dst адрес на НСДИ при выходе (только при условии, что в пакете содержится именно DNS запрос). У моего провайдера ТСПУ стоит после BRAS'a (PPPoE сервер фактически), у меня белый адрес, соответственно провайдерского CG-NAT в моём случае нет.
Я пробовал так же из интернета отправить самому себе DNS ответ заблокированного домена подделав src адрес на 8.8.8.8, подмены DNS ответа не произошло.
Я не представляю себе, как они через Android API собрались получать IMEI, IMSI и MAC-адрес. А в мобильных сетях понятия мака вообще не существует.
Ситуация просто сюр
Если очень сильно захотят, то могут выпустить серт от УЦ минцифры на домен Ютуба, отдавать на DNS серверах НСДИ IP-шник сервера который будет редиректить на рутуб.
Звучит как какой-то пранк.
Сможет, но если MITM будет только на 443 порту, тогда DoH сервер можно разместить на другом.
Относительно перехвата DNS запросов со стороны операторов связи у меня есть следующие наблюдения:
Эр-телеком: подмены dst адреса нет, при использовании стороннего резолвера используется реально введённый DNS сервер в настройках системы или роутера (это видно по пингу и по всяким различным тестам "DNS утечки"), однако при попытке резолвинга заблокированных доменов по реестру, будет отдаваться IP-адрес заглушки (отдаёт так же только по UDP). Они отдают заглушку даже если резолвить домены извне:
При этом реального DNS сервера на
188.187.188.255- нет(IP-адрес был взят наугад)
Уфанет: подмены ответа при использовании других резолверов нет, но на операторских DNS серверах заблокированные домены по реестру не резолвятся
Ростелеком: на их резолверах отдаётся в ответе
127.0.0.1при резолвинге фейсбука или инстаграма, с остальными ресурсами по типу рутрекера всё хорошо, при использовании сторонних серверов отдачи заглушки нетПринцип работы перехвата DNS эр-телекома и ТСПУ значительно отличаются.
Ничего не мешает поднять свой приватный DoH сервер и пользоваться им (если публичные перебанят, или если ГРЧЦ/ЦМУ ССОП начнёт путём сканирования всего интернета искать DoH сервера дёргая GET/POST /dns-query и блокировать их)
Через DNS тоже можно отдавать A/AAAA записи самого прокси сервера, но в случае использования DoH провести MITM не получится.
А TXT записи резолвятся через восьмёрки в незашифрованном DNS? Если исходящий и входящий трафик проходят через разные ТСПУ, то вряд ли трансляция адресов будет корректно работать в этом случае, ответ придёт далеко не от 8.8.8.8
Вы можете и самостоятельно экспериментировать, если у вас нет перехвата DNS запросов, то вы можете найти хостинг с подобным явлением из этого списка - https://globalping.io/?measurement=2TnuCfL63NIYzgR1Y001211g2&display=table
Могу лишь предположить, что ТСПУ перестаёт делать DNAT после получения ICMP TTL Exceeded:
Но при резолвинге по несколько раз с TTL 64 в рамках одного соединения отдаёт NXDomain стабильно (за исключением случая кратковременно большого pps/rps, как это описано в статье):
По пути у меня нет узлов, которые бы не отдавали ICMP TTL Exceeded.
Если учитывать текущую техническую реализацию (а реализовано оно усечённым, легковесным и одновременно странным DNAT), то 443 порт должен уходить на какой-то сторонний прокси сервер в интернете, этот самый прокси должен по SNI отрезолвить домен, в результате чего исходный IP-адрес клиента просто потеряется (если его не добавлять отдельным заголовком конечно), это сломает веб-ресурсы, которые доступны только по белым спискам src адресов.
Если конечно, ТСПУ не научится в полноценный MITM в рамках TLS без потерь IP-адресов, или если провайдер не разместит прокси сервера у себя.
Получил NXDomain при отправке DNS запроса через 3 секунды после рандомного пакета:
Интервала как такового нет, даже через 1 секунду такой же результат
С реальным DNS запросом при TTL 2 такая же ситуация, подождал целую минуту, а в ответ пришли настоящие IP-адреса:
Проверил резолвинг TXT записей, они не перехватываются (DNAT не происходит)
Во будет анекдот, если 9.9.9.9 начнут перехватывать, а потом у него снова всё сломается)
В данном случае ТСПУ не занимается подделкой DNS ответа, он просто меняет dst адрес на НСДИ при выходе (только при условии, что в пакете содержится именно DNS запрос). У моего провайдера ТСПУ стоит после BRAS'a (PPPoE сервер фактически), у меня белый адрес, соответственно провайдерского CG-NAT в моём случае нет.
Я пробовал так же из интернета отправить самому себе DNS ответ заблокированного домена подделав src адрес на 8.8.8.8, подмены DNS ответа не произошло.
Пока перехватывают только определённые DNS сервера