Комментарии 14
Сегодня они рекомендуют использовать те серверы, которые ближе к телу, завтра начнут требовать, а послезавтра светлые умы, пилящие ПО для фсбшных коробок, доделают подмену запросов на лету. Нет уж, спасибо — лучше мы потерпим лишние 20 мсек и получим данные устойчивым к шаловливым ручкам способом.
Ну тут кейс не отрицает шифрованные каналы к альтернативным серверам. VPN в цивилизацию в наше время - суровая необходимость.
Надо помнить, что DoH/DoT (если речь шла про них), к сожалению, детектируются ТСПУ без сложностей.
И кстати да, они не рекомендуют, они требуют. Штрафы на неподключение уже выставляются.
Так продолжаем цепочку: "НСДИ детектирует подключение к ней по наличию запросов, но совершенно не может определить, что вы делаете с ответами." Соответственно, НСДИ не знает сколько из вашей сети реально было запросов к DNS и сколько % вы направили на эти NS.
При использовании bind: forwarders честные, и forward first (пытаемся запросить самостоятельно, начиная с корневых).
forwarders {ip порт, ip порт...} - указывает адреса хостов и если нужно порты, куда переадресовывать запросы (обычно тут указываются DNS провайдеров ISP).
forward ONLY или forward FIRST - параметр first указывает, DNS-серверу пытаться разрешать имена с помощью DNS-серверов, указанных в параметре forwarders, и лишь в случае, если разрешить имя с помощью данных серверов не удалось, то будет осуществлять попытки разрешения имени самостоятельно.
Кстати, и мой вариант и ваш - отправка запросов на 53 куда не надо "детектируются ТСПУ без сложностей."
опционально (если почему-то не очень доверяете НСДИ)
Давайте подумаем, почему же мы не очень доверяем НСДИ.
Возможно, потому что она резолвит не все домены?
"Список нерукопожатых доменов, как и в случае с ТСПУ, непубличен.
А может потому, что этот говна кусок порой резолвит аж целых 3 секунды?
Нет, если бы они сделали такой клёвый, устойчивый к отключению от корня и обрубанию снаружи DNS, который отвечает за 1-10 мс, то мы бы с радостью. Но ведь сделали в точности наоборот: ещё один уровень фильтрации, к тому же тормозной.
Возможно, потому что она резолвит не все домены?
ну а домру отдаёт свои ответы на dns-запросы по «не всем» доменам (независимо от адреса сервера, к которому изначально был адресован запрос)
$ dig +short navalny.com @8.8.8.8
188.186.157.49
$ dig +short navalny.com @11.12.13.14
188.186.157.49так лучше? )
Решение простое как блин, в общем-то. НСДИ детектирует подключение к ней по наличию запросовА если, грубо говоря, в файлик напихать 100500 доменов и бомбардировать НСДИ запросами в случайном порядке. Нехай жрут. К боевой системе этот эмулятор никак не подключать.
Можно так, но если они начнут профиль трафика смотреть в перспективе - могут возникнуть вопросы. Ну, условно, вся страна в едином порыве бросилась смотреть пресс-конференцию Путина - а у нас в резолве что-то из далекого прошлого запрашивается. Я бы на их месте такой анализатор запилил, это не очень сложно.
Вся страна бросилась смотреть одно и то же, а наш резолвер закэшировал один раз, и отдаёт всем абонентам из кэша. Никакая "массовость" не будет заметна на НСДИ, если конечно TTL записи не 10 минут
Сейчас активно применяются низкие значения TTL. У amazon.com, например, 1 минута.
В целом для описанного варианта "100500 доменов из файла" решение есть, оно простое - https://dns-shotgun.readthedocs.io/en/stable/
Но мне чисто интуитивно оно некомфортно, я предпочту сливать живой поток запросов через один из описанных методов.
Эй, ямщик, поворачивай к черту, этой дорогой поедем домой. Заказали бы у Яндекса нормальный НСДИ, с красивым адресом, самый быстрый. У них опыт, не пропьешь. И потихоньку стали бы cdn ить, маршруты бы пошли.
За такое НСДИ 90 лет назад могли бы административно наказать. Холостым, то есть абсолютно одиноким, патроном, как говаривал Жванецкий, земля ему пухом.
Как и к НСДИ подключиться, и рыбку съесть