Comments 6
чтобы защитить содержательную часть DNS, необходимо использовать DNSSEC
Позвольте подушнить: DNSSEC защищает ее только при транспортировке и никак не может помешать отправке любой белиберды, если ее передает источник ответа, и получению оной же, если агент пользователя не поддерживает DNSSEC (что происходит чуть реже, чем всегда).
DNSSEC защищает ее только при транспортировке
Преимущество DNSSEC как раз в том, что администратор DNS-зоны подписывает конкретные сведения в этой зоне. Администратор является первоисточником сведений о настройках зоны, так или иначе. Поэтому, если мы принимаем, что подпись работает и подписывающие ключи сохраняются администратором в секрете, то для стороны, валидирующей DNS-записи, вообще становится без разницы, откуда и как эти записи были получены - главное, чтобы сходились подписи и все ключи в цепочке были доверенными. То есть, DNSSEC как раз делает DNS-данные независимыми от транспорта. Конечно, это не защищает от того, что записи всё же кто-то испортит на транзите, но подменить содержание, скрыв факт подмены, не получится, так что порчу можно будет обнаружить.
и никак не может помешать отправке любой белиберды
Это так. Администратор волен написать в DNS-зоне что угодно, в том числе, может корректно подписать "кривые" записи или наделать "кривых" ключей, может ещё что-то сломать под своими именами, подтвердив все поломки DNSSEC-записями. Однако в случае, когда DNSSEC нет, всё это может проделать не только администратор, которому по статусу положено, но и всякий транзитный узел.
А главный недостаток DNSSEC в том, что это слишком хрупкая, по нынешним временам, технология, требующая, к тому же, специальных знаний и понимания принципов работы для поддержки уже настроенных процессов. И когда хрупкость DNSSEC даёт о себе знать, тогда отламываются сразу целые национальные зоны.
Как скрыть свои запросы от провайдера с помощью этой штуки?
Достаточно указать внешний, относительно провайдера, рекурсивный резолвер, включить для этого резолвера DoH и убедиться, что защищаемые DNS-запросы действительно ходят через DoH на этот резолвер. Если прошивка роутера позволяет, то можно настроить на роутере локальный резолвер в качестве "форвардера", указав в качестве вышестоящего рекурсивный резолвер с DoH или DoT и выбрав один из этих протоколов для доступа. Соответственно, на всех устройствах в LAN тогда нужно настроить в качестве DNS-сервера IP-адрес роутера (или роутерного резолвера). Это настраивается через DHCP или вручную на устроствах (в настройках DNS). Тогда локальная работа с DNS будет в открытом виде, но за пределы LAN DNS-трафик будет ходить через DoH/DoT, которые настроены на роутере для "форвардера". То есть, устройства в локальной сети используют в качестве резолвера роутер, а внутри роутера запросы оборачиваются в DoH/DoT (на этот момент нужно обратить внимание) и передаются на внешний, относительно провайдера, рекурсивный резолвер в защищённом виде.
Почему указание резолвера на роутере не даёт эффекта?
Точно сказать сложно, зависит от сетевой конфигурации. Скорее всего, потому, что устройства обращаются к внешнему DNS-резолверу напрямую, без всяких DoH/DoT, например, получив такой адрес резолвера по DHCP. Кроме того, сам по себе адрес - не говорит о том, по какому протоколу нужно подключаться. Если по умолчанию, то всё будет ходить в открытом виде, даже если указать IP-адрес сервиса резолвера, который, потенциально, поддерживает тот же DoH. То есть, нужно не только настроить защищённый DNS-доступ на DNS-подключении роутера, но ещё и устройствам в локальной сети рассказать, что нужно использовать именно защищённую точку входа для DNS, особенно, если эти устройства не поддерживают DoH/DoT (см. про "форвардер" выше).
Клиентским устройствам совершенно не интересно, по какому протоколу резолвер на роутере общается с вышестоящим резолвером (апстримом). И поддержка защищённого DNS со стороны клиентов вовсе не нужна. Более того, она может быть вредна, поскольку ПО на клиенте (допустим, браузер) начнёт использовать свою встроенную реализацию в обход резолвера на роутере.
Что реально нужно сделать, так это:
1) убедиться, что резолвер на роутере общается с апстримом исключительно по защищённому протоколу
2) убедиться, что все клиентские устройства в локальной сети адресуют свои запросы именно резолверу на роутере, а ПО на этих клиентах не использует встроенную реализацию "безопасного DNS" (если таковая в нём есть). То, что клиентские устройства с резолвером роутера общаются по стандартному 53 порту через plain-text DNS - не играет роли, если только вы не опасаетесь, что кто-то прослушивает трафик внутри вашей локалки. Таким образом, между клиентами и роутером DNS-трафик бегает нешифрованный, а уже на этапе между роутером и апстримом - шифрованный.
3) опционально можно настроить на роутере правило, перехватывающее весь трафик из локальной сети по 53 порту и принудительно заворачивающий его на 53 порт роутера. Таким образом, если даже в сетевых настройках у какого-то клиента явно указан адрес публичного DNS-сервера, эти DNS-запросы обработает резолвер на роутере.
И поддержка защищённого DNS со стороны клиентов вовсе не нужна.
Это как посмотреть. Конечно, сокрытие запросов от провайдера - не требует DoH внутри: если весь процесс резолвинга для устройств в локальной сети зведён на резолвер роутера или на другой конролируемый резолвер, тоже внутри LAN, то хорошо. То есть, решается именно задача закрытия DNS-трафика между "пограничным" резолвером и внешним резолвером. Но вообще, основной смысл DoH - именно в защите от приложения к приложению, то есть, даже выше уровня устройства. Другое дело, что DNS требуется примерно везде, однако на произвольных устройствах - DoH большая редкость.
Таким образом, если даже в сетевых настройках у какого-то клиента явно указан адрес публичного DNS-сервера, эти DNS-запросы обработает резолвер на роутере.
Кстати, это как раз пример подмены DNS. Клиент обращается к 8.8.8.8, а отвечает - (ближайший) роутер. Для борьбы с чем, собственно, и предлагается DoT/DoH, но в приложении на клиенте. Момент, с точки зрения администрирования LAN, спорный; регулряно выдвигается в качестве одной из основных причин того, почему "DoH в браузере - плохо". Но тут просто разные парадигмы.
Как HTTP(S) используется для DNS: DNS-over-HTTPS на практике