Ничего не мешает поднять свой приватный 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 ответа не произошло.
Ничего не мешает поднять свой приватный 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 сервера