Комментарии 9
Относительно компаний с закрытыми корп сетями: корп сети и так обычно настраивают на получение корпоративного DNS сервера, т.е. подменить запрос DNS можно только внутри самой корп сети. Риск описанный в статье не исключён, но ограничен только корп сетью компании. В плане удалённой работы, то корпоративные VPN-решения, например, VPN от Fortinet самим VPN-клиентом подменяют глобально на пк/ноуте пользователя DNS сервера, и пользователь при активном VPN обратится к корпоративному DNS серверу (мне это даже доставляло иногда неудобства, ибо надо было иногда заходить с личного пк на запрещённые компанией ресурсы. Хех). В таком случае запрос DNS с пк/ноута пользователя с компа уходит в VPN-туннель в корп сеть компании.
Остаются компании, где подобных высоких требований по доступам в интернет с рабочего места нету. Но им скорей всего подобная функция и не будет особо важна. Хотя как знать, если для этого не надо будет покупать каких-то корпоративных подписочных лицензий (которые майки очень любят, куча разных лицензий на office365, подписки на виртуализацию в Azure... и т.д. )) ), то руководство может и нагрузить админов и такой работой).
А я не понял, а зачем? Ведь можно же поднять dot doh на корп сервере, через прямое обращение к root серверам, и там рулить правилами.
Читайте оригинал, там объясняется. Приложение (особенно вредоносное) может проигнорировать ваш корпоративный сервер (где вы рулите правилами) и гонять запросы к DNS-серверу, который оно предпочитает использовать (который не осуществляет фильтрацию). Ну вот не стал малварщик в своей малвари реализовывать подхват адреса корпоративного DNS из системных политик, негодяй такой. Вместо этого он встроил в малварь клиент DNS-over-HTTS, чтобы пулять запросы к https://dns.google и скрывать это от вас.
Поэтому, чтобы не заниматься перехватом незашифрованного DNS, блокировать DoT и, что сложнее, DoH, или обнюхивать SNI (что затратно по ресурсам и с распространением ECH становится невозможным) по умолчанию блокируем весь исходящий трафик, кроме DHCP и Protective DNS. Когда приложение пытается резолвить через ZTDNS, то отрезовленные IP помещаются в белый список (если они на корп. сервере не в чёрном списке) и с ними можно установить исходящее соединение.
Когда вредоносное приложение пытается резолвить через что-то стороннее (обычный сторонний plain-text DNS/DoT/DoH/DNSCrypt), то если оно даже и отрезолвит свой управляющий домен, то установить связь с отрезолвленным IP-адресом не сможет, потому что он не добавился в белый список.
Просто у существующих DNS есть фатальный недостаток.
Ох, майки...
Теперь дошло до усложнения жизни передовых юзеров, вплоть то подобия "корпоративной сети" дома. Хотя, если эта фича и выйдет в релиз, то не факт, что до России дойдет, так же, как и большинство фич от Apple...
До сих пор никто не мог одновременно решить задачи E2E-шифрования и администрирования DNS, которые частично взаимосключающие. Обычно трафик или отправляется открытым текстом, или шифруется так, что администраторы не могут его нормально отслеживать и фильтровать.
ZTDNS - это же получается аналог опции ipset в dnsmasq? Тогда в чем инновация то?
чувствую как много будет вони когда сломаются все каптив порталы как в ведроиде с DoH..
Инициатива по интеграции DNS в Windows 11 вызывает опасения экспертов