Use doh server mikrotik что это
Skurudo Blog(post)
Второго дня в версии 6.47 ветки stable завезли поддержку DoH (DNS over HTTPS). До этого оно было только в ветке с beta и использовать ее не очень хотелось в виду отсутствия стабильности. Почему это так важно? Дело в том, что DNS без каких-либо дополнений дает возможность вышестоящему провайдеру смотреть и подменять dns-запросы. Не видно причин, зачем ему давать такое делать. А также есть некая простота в том, что теперь свои dns-запросы не нужно заворачивать в тот же VPN.
DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода >является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и >манипулирования данными DNS с помощью атак типа «Атака посредника».
Первым делом нужно обновиться до 6.47 в ветке stable (или воспользовать beta). В случае с long-term стоит либо потерпеть и подождать или переключиться на stable.
Теперь нужно провести небольшую артподготовку, а именно скачать и импортировать список корневых сертификатов. Делается это двумя командами:
Также список корневых сертификатов можно взять на сайте haxx.se или же с DigiCert
После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:
Провести проверку можно с помощью torch или в connection tracker:
Список DoH серверов — смотреть тут, но самые популярные скорее всего будут Google ( https://8.8.8.8/dns-query ) и Cloudflare ( https://1.1.1.1/dns-query ).
Тестируем и проверяем на сайте Cloudflare
На всякий случай привожу листинг команд:
UPDATE: Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare 🙂
MikroTik-DOH
Настройка DoH в RouterOS
Главное помните в production есть место только long-term релизам, не о каких stable и тем более testing не идёт и речи.
Сегодняшняя тема пойдёт о функционале DoH который перекочевал из ветки testing в stable.
Для чего DoH необходим или нужен?
В первую очередь защититься от подмены DNS сервера и естественно ответов с таких серверов, многие провайдеры очень любят заниматься такими делами (привет домру).
Для чего провайдеры это делают?
Во-первых, чтобы вы не отправляли в интернет трафик который отправить у вас не получиться, например на хосты которые требует заблокировать РКН, дело в том, что провайдеру значительно дешевле поднять пару ДНС серверов и перенаправить ваши запросы на свои сервера, чем фильтровать огромный объём трафика. Провайдер в любом случае должен его фильтровать, но согласитесь если относительно дешёвым способом можно снизить нагрузку на пакетный фильтр. Да да я знаю, что некоторые использую blackhole.
Во-вторых провайдер может собирать по вашим запросам статистику, например вы часто ходите по порносайтам, как итог получите рекламу мази от мозолей. (Шутка но смысл вы поняли) причём как с некоторым провайдерами рекламы вы можете получить как изменённый незашифрованный HTTP трафик (привет домру), например добавят на все страницы javascript который будет вам показывать, что-то не то. Минус такого подхода заключается в том, вот решили вы подарить своей супруге путешествие на Мальдивы, открыли сайт мальдивы.рф и после этого реклама от вашего провайдера будет пестреть мальдивами на всех устройствах и на вашем и на устройствах вашей супруги. А ведь вы можете искать, что-то и другое.
Так вот, а так как провайдер, а точнее любой хост кроме вашего компьютера и сервера назначения (исключение прокси с корневыми сертифактами) не может посмотреть, что идёт внутри HTTPS сессии так как она зашифрована, он может посмотреть только SNI имя хоста, и то это уже значительно дороже для вычислительных операций, и я предполагаю цена рекламы не окупит цену обслуживания и самой железки которая сможет фильтровать SNI имя хоста в канале допустим в 10G.
Именно для того чтобы ваши запросы не мог перехватить и подменить кто-то третий, была придумана реализация DoH. Но здесь есть обратная сторона медали, если вы использовали ДНС сервера провайдера или позволяли перехватывать трафик провайдеру, то только провайдер знал куда вы реально ходите в интернет на какие адреса. А когда вы будете использовать публичные ДНС сервера DoH например Гугл, то это значит, что теперь Гугл будет знать куда вы ходите и будет вам подсовывать соответствующую рекламу. тут исключительно дело вкуса.
Есть ещё одна сторона, третья, допустим ваш клиент это известный человек в публичном пространстве или просто успешный человек с финансовым достатком и конечно человек семейный, и он любит ходить «на лево», отследить по ДНС запросам значительно проще провайдеру так как он знает, какой реально человек стоит за запросом, и согласитесь если запросы идут, сначала на сайты знакомств\досуг, а потом Цветы, гостиницы и тд.. можно провести некую параллель, а теперь представьте такая информация досталась Васе Пупкину сотруднику провайдера, который недоволен жизнью, зарплатой и личной жизнью, и решил «по легкому срубить бобла». Публичному серверу это будет сделать значительно сложнее в виду огромного количества запросов и сложностью сопоставления с реальным человеком, хотя и возможно. Отдельным особняком стоят люди которые имеют доступ к секретной\закрытой информации или могут принимать управленческие решения в гос-ве, в таком случае может быть всё наоборот.
И так начнём.
DoH стандартизирован и работа с ним описана в документа RFC8484
Мы разберём на примере двух серверов.
Первым делом нам необходимо выяснить по какому url необходимо отправлять запросы, привожу список страниц на которых указаны url для запросов.
И сами урл-ы, чтобы вам лишний раз не лазить.
На данный момент MikroTik поддерживает только один сервер, но прелесть в том, что, так как к ДНС серверу мы обращаемся по доменному адресу, DoH провайдеры могут сделать DNS-RR для данных записей A записей и они будут зарезервированный ну или могут смениться без перенастройки оборудования с вашей стороны. Вы только представьте если завтра Гугл скажет, что они решили изменить 8.8.8.8 на 8.8.9.9 мир рухнет =).
Обратите внимание, что схема URI должна быть обезательно https
Установим сервер и обязательно поставим галочку отвечающую за то, что будет проверяться SSL сертификат сервера, иначе прилетит ответ с не валидным сертификатом от провайдера «и пиши пропал», начинай всё сначала.
Либо вариант через CLI
А так же для резольвинга самой записи нам понадобиться любой ДНС сервер, можно от провайдера можно от гугла это без разницы.
Сразу проверим работу DNS
Как видите запрос не прошёл, посмотрим кэш
Видим, что в КЭШ только адрес нашего DoH сервера, после того как вы указали DoH сервер резольвиться адрес с помощью обычного ДНС сервера будет только адреса DoH серверов.
Почему не работает?
Дело в том, что мы установили параметр verify-doh-cert что означает проверять SSL сертификат, но сверять сертификат RouterOS не с чем и некому доверять так как в RouterOS нет корневых сертификатов центров сертификации, по народному CA.
Как узнать какой CA нужно установить?!
Очень просто, нам необходимы выяснить какой CA выдал сертификат.
Вы найдёте на просторах уже инструкции, что можно скачать сам сертификат основной который висит на сайте, на сомом деле это не обязательно, можно скачать CA сертификат который подписал непосредственно данный сертификат или подписал CA которых стал промежуточным CA и подписал конечный сертификат. Проще, скачать и доверять самому верхнему сертификату в цепочке. Единственный какой может быть тут подвох, в том, что у таких сертификатов отсутствует CRL пусть к проверке отозванных сертификатов, но мы не будет сейчас затрагивать данную тему.
Unix-like
Нас интересует владелец и видим что его выдал DigiCert
Windows
Для тех у кого WIndows идём в
и открываем адрес Doh сервера допустим хромом и смотрим какой сертификат, а точнее кто выдал видим что это DigiCert
Идём в Гугл и находи сайт CA DigiCert и по ключевому слову download ищем страницу загрузки CA сертификатов, находим нужный сертификат, качаем.
Прежде чем копировать сертификат на Микротик, откройте (не устанавливайте) его в вашей операционной системой и убедить, что ему ОС доверяет, если не доверяет значит вы скачали не то или не оттуда.
Если всё хорошо, скопируйте сертификат на Микротик и выполните команду импорта сертификата
Всё должно работать, проверяем.
Настоятельно рекомендую не пользоваться скриптами из интернета, всё, что касается сертификатов, сделайте пару раз руками, дальше пойдёт как по маслу. Если вы ещё не готовы понимать того, что написано в скрипте, то откажитесь от автоматической генерации и скачивании сертификатов, особенно если там встречаются короткие ссылки который по факту непонятно куда могут привести и не понятно какой сертификат скачать.
Я специально не привожу готовые сертификаты а только ссылки на них, пожалуйста убедитесь что вы скачиваете сертификаты именно с нужного сайта (наш сайт тоже могут ломануть =)) )
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Настраиваем использование DNS over HTTPS (DoH) на роутерах Mikrotik
Чтобы понять суть проблемы незащищенного DNS немного углубимся в историю: на заре формирования глобальной сети интернет в том виде, в каком мы ее знаем встал вопрос использования простых и запоминающихся имен вместо цифровых адресов. Для того чтобы решить эту задачу был создана система DNS, которая должна была хранить соответствия имен цифровым адресам и сообщать их, получив запрос по специальному протоколу. Со временем возможности DNS росли и расширялись, но основной функцией по-прежнему остается сопоставление доменных имен IP-адресам, это одна из ключевых служб современного интернета, обойтись без нее невозможно.
В далеком 1987 году, когда принимались первые спецификации DNS вопросы безопасности были далеко не на первом месте и поэтому протокол дожил до наших дней практически в первозданном виде, передавая данные без какой-либо защиты. Чем это чревато? Давайте посмотрим.
При этом, обратите внимание, абонент не использовал DNS-сервера провайдера, а работал с публичными серверами Google, но все равно провайдер имеет полную картину запросов пользователя. Эта же самая информация доступна каждому промежуточному узлу, через который проходит абонентский трафик.
К сожалению, это не так. Информацию на основе ваших DNS-запросов могут использовать в рекламных целях и далеко не факт, что это будет ненавязчивая реклама в браузере. Кроме того, она позволяет составить достаточно наглядную картину вашей интернет-деятельности и далеко не все ее эпизоды вы захотите сделать общественным достоянием. Причем речь тут даже не о каких-то порочащих моментах, но вряд ли широкой общественности надо знать, что вы храните деньги в банке А и регулярно делаете покупки на площадке Б.
Чтобы избежать раскрытия данных о DNS-запросах был реализован протокол DNS over HTTPS (DoH), который осуществляет взаимодействие с DNS-серверами по защищенному HTTPS-каналу, что исключает перехват запросов, теперь о вашей интернет активности будете знать только вы и DNS-сервер.
В RouterOS возможность использовать DoH появилась начиная с версии 6.47, но в ней имеется ряд уязвимостей, которые могут привести к утечке DNS, поэтому минимальной версией для DoH следует считать 6.47.1.
Здесь возникает один интересный парадокс: DoH-сервер указан в виде URL, и чтобы достичь его нам нужно будет выполнить разрешение имен на обычном DNS-сервере. Поэтому в настройках выше у вас должен быть указан хотя бы один DNS-сервер. Наиболее правильно будет не трогать текущие настройки DNS, так как при указании DoH все запросы будут автоматически направляться к нему. Таким образом ваш провайдер будет знать, что вы используете DoH, но ваша интернет активность будет от него полностью скрыта.
Вроде бы все настроено правильно, но после применения данных настроек доступ в интернет на клиентах пропадет. А в качестве причины будет указана невозможность разрешения DNS-запросов.
В чем же дело? А дело в флаге Verify DoH Certificate, который предписывает роутеру проверить предъявляемый DoH сертификат. Можно, кончено, обойтись и без проверки, но это позволит любому злоумышленнику перехватить запрос и отправить собственный ответ, который будет принят роутером, что сведет на нет весь смысл защиты DNS с помощью HTTPS.
Но почему сертификат не проходит проверку? Да потому что RouterOS не имеет возможности ее выполнить. Для того чтобы проверить валидность сертификата нам потребуется корневой сертификат центра сертификации (CA), во «взрослых» ОС такие сертификаты хранятся в защищенном системном хранилище и обновляются средствами системы, в RouterOS нам нужно добавить такие сертификаты самостоятельно.
Корневые сертификаты CA не являются секретными, но именно они отвечают за доверие ко всем выпущенным этим удостоверяющим центром сертификатам, поэтому скачивайте их только с официальных источников (на нашем сайте ссылки именно оттуда) и обязательно проверяйте контрольные суммы, которые отображаются в колонке Fingerprint на Mikrotik.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
MikroTik поддерживает DNS over HTTPS (DoH)
Начиная со стабильной версии 6.47 MikroTik поддерживает DNS over HTTPS (DoH).
Далее краткая инструкция по настройке с проверкой сертификата сервера на примере Cloudflare.
1) Импортируем сертификат DigiCert Global Root CA в хранилище сертификатов роутера:
2) В поле Use DoH Server пишем https://1.1.1.1/dns-query и ставим галку Verify DoH Certificate:
3) Убираем все существующие DNS-сервера, чтобы поля Servers и Dynamic Servers (из DHCP Client) были пустыми и все запросы шли через DNS over HTTPS (не обязательно для 6.47.1+).
Проверить корректность настройки можно на странице https://www.cloudflare.com/ssl/encrypted-sni
MikroTik поддерживает DNS over HTTPS (DoH) : 36 комментариев
Доброй ночи. Не работает, Попробовал на HAP AC2. Не обнаруживает DNS.
Либо настроили неправильно, либо провайдер шалит, причём первое вероятнее.
Для CloudFlare DoH
Проверять можете так же в терминале командой
Ну и смысл дублировать мою инструкцию?
Третий пункт, похоже, лишний: на данный момент если указан сервер DoH, все запросы идут к нему.
Похоже в 6.47.1 это исправили, на прошлой необходимость была.
Рад видеть специалиста 😉
В листе WAN надо что нибудь включать/исключать (Include/Enclude) интерфейсы
если правлю файрвол, dns перестает работать. без этого все поднялось, но первый пункт в проверке не cloudfare не проходит.
Что-то у меня не получается убрать все Dynamic Servers в DNS Setting.
Убрал галку Use Peer DNS в DHCP Client, но Dynamic Servers все равно есть.
На входном интерфейсе WAN тоже убери галочку.
Инструкции из поста автора недостаточно для полной настройки. Firewall тоже необходимо уделить внимание, например изолировать локальный DNS от внешней сети интернет.
Добрый день!
Сделал все согласно инструкции но настранице теста ни internet explorer ни chrome не проходят тест Encrypted SNI.
Эти браузеры его не поддерживают. ESNI (Encrypted SNI) будет работать в Mozilla Firefox.
К сожалению в нем такой же результат.
Просто установить браузер недостаточно. Первая инструкция в поисковике по запросу «Mozilla Firefox ESNI» поможет его настроить.
Если Firefox настраивать как вы говорить, то он и сам в нужном режиме может работать (и работает кстати) без оглядки на то что мы в роутере прописали. А если так то какой смысл возни с роутером? Вот здесь (http://www.opennet.ru/tips/3120_chrome_firefox_dns_doh_https_crypt_privacy.shtml) разбирали подробно этотт вопрос. У меня так то работало, но я думал что можно настроить это всё на роутере, чтобы не заморачиваться настройкой браузеров на каждом устройстве, особенно на планшетах и телефонах.
По инструкции настраивается DNS over HTTPS, а не Encrypted SNI.
всё работало, но через пару дней перестало, отключаешь DOH интернет работает.
у кого так же? провайдер ростелеком начал блокировать это?
У кого отвалился или не работал изначально — добавьте статическую запись для самого DNS-сервера:
/ip dns static
add address=116.202.176.26 name=doh.libredns.gr type=A
Ну или какой там у вас используется
Именно поэтому во втором пункте указан IP-адрес.
MikroTik поддерживает DNS over HTTPS (DoH)
Начиная со стабильной версии 6.47 MikroTik поддерживает DNS over HTTPS (DoH).
Далее краткая инструкция по настройке с проверкой сертификата сервера на примере Cloudflare.
1) Импортируем сертификат DigiCert Global Root CA в хранилище сертификатов роутера:
2) В поле Use DoH Server пишем https://1.1.1.1/dns-query и ставим галку Verify DoH Certificate:
3) Убираем все существующие DNS-сервера, чтобы поля Servers и Dynamic Servers (из DHCP Client) были пустыми и все запросы шли через DNS over HTTPS (не обязательно для 6.47.1+).
Проверить корректность настройки можно на странице https://www.cloudflare.com/ssl/encrypted-sni
MikroTik поддерживает DNS over HTTPS (DoH) : 36 комментариев
DoH server connection error: SSL: handshake failed: unable to get local issuer certificate (6)
в логах такая ошибка
Видимо вы не добавили сертификат из первого шага.
Нет, всё работает, видимо вы не настоящий админ.
Возвращение 400 это работает называется?
400 = 200 уже?
Его нужно не в браузере открывать, а в микротике прописывать, у меня до сих пор работает.
Он лишь в Curl’е иногда проскакивает что работает.
В микротике тоже отказывается.
У них в DoH мане теперь написано что нужно указывать домен, т.е. что бы юзать DoH, нужно юзать чей то DNS.
У гугла та же история теперь, по этому DoH в той самой изначальной идее уже больше мёртв, чем жив, т.к. остальную мелочь из поставщиков DoH не рассматриваем.
Укажите домен статикой будет вам счастье.
И искать потом приключения на удалённых узлах, когда он вдруг сменится?
Хороший такой совет.
перестало сегодня работать
DoH server connection error: SSL: handshake failed: certificate is not yet valid (6)
DoH server connection error: Connection refused
не смог заставить работать
и серт перекачал
Как вариант, снимите галку с пункта verify-doh-cert=
Спасибо за инструкцию.
Всё работает как надо.
После я усложнил схему. Я ещё и WARP Cloudflare подключил через WireGuard (в RouterOS 7.1) и смаршрутизировал запросы на 1.1.1.1 в тоннель.