Если очень сильно захотят, то могут выпустить серт от УЦ минцифры на домен Ютуба, отдавать на 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 ответа не произошло.
Ситуация просто сюр
Если очень сильно захотят, то могут выпустить серт от УЦ минцифры на домен Ютуба, отдавать на 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 сервера