Техническое: эксперимент с резолверами и DNSSEC
По адресу http://hold-my-beer.xyz/ (да, он несколько странный, но правильный) – я разместил веб-интерфейс экспериментального сервиса, который пытается определить, поддерживает ли ваш DNS-резолвер валидацию DNSSEC. Довольно давно я уже сделал сервис, проверяющий поддержку DNSSEC при помощи браузера. Отличие нового эксперимента в том, что здесь проверка происходит также и на серверной стороне, а в браузер передаются адреса резолверов – как они видны на авторитативных серверах. То есть, методика измерения совсем другая, более полная, так как позволяет собирать статистику. Но, повторюсь, это пока эксперимент.
Для проверки – достаточно зайти браузером по ссылке. Там есть и визуальный “флаг”, который покажет, поддерживается ли валидация DNSSEC (вверху страницы, зелёный/красный). Сразу оговорю технический момент, связанный с сервисом резолвера Google Public DNS (8.8.8.8): этот сервис заявлен как валидирующий, но в случае данного теста – браузер покажет, что поддержки DNSSEC нет. И это действительно так. Причина в том, что для теста используются имена (DNS-зоны) четвёртого уровня и ниже, и здесь сервис Google почему-то не проводит валидацию (возможно, так задумано, возможно – это ошибка: нужно будет написать в Google). При использовании, например, Cloudflare (1.1.1.1) – всё работает нормально, как ожидается.
(Это временный сервис, точнее – демонстратор технологии.)
Update (25/07/2019): эксперимент закончен, сервис пока недоступен.
Адрес записки: https://dxdt.ru/2019/03/15/8738/
Похожие записки:
- Port knocking как инструмент управления доступом к скрытым сервисам
- CVE-2024-3094 про бэкдор в liblzma и теория ИБ
- Внешние библиотеки на сайтах и замена кода
- DNS-over-TLS на авторитативных серверах DNS
- Появилась поддержка DMARC/SPF на сервисе audit.statdom.ru
- CVE-2024-31497 в PuTTY
- Год 2022, новый
- Техническое описание TLS: обновление 2022
- Open Source и добавление "вредоносного кода"
- LLM и "Яндекс.Поиск"
- Подмена хостнейма WHOIS-сервиса .MOBI
Комментарии читателей блога: 4
1. 16th March 2019, 08:19 // Читатель Nataraj написал:
Эта… интересное поведение.
У меня стоит uMatrix и скрипты с nox.su были запрещены. И вот пока они были запрещены, мне показазали DNSSEC OK. А как только я из разрешил — стало красным…
В современном вебе походу надо штатно закладываться на то что с части доменов скрипты работать будут, а с части — нет…
2. 17th March 2019, 01:58 // Читатель Влад написал:
Что-то пошло не так :)
Вообще, не проще ли просто в маршрутизатор на openwrt (или подобном) поставить dnscrypt и забыть об этой проблеме раз и навсегда для всех браузеров в локальной сети?
3. 17th March 2019, 15:03 // Александр Венедюхин:
> И вот пока они были запрещены, мне показазали DNSSEC OK.
Это, видимо, потому, что скрипты с http://hold-my-beer.xyz/ – были разрешены. В принципе, нужно бы там как-то это тоже отслеживать, например, вынести проверку доступности тоже в зону nox.su, видимо, я так и сделаю. Вообще, пока не придумал простой и разумный универсальный способ: ну, то есть, довольно сложно определить, что там и как у клиента исполняется, а что – не исполняется, и по какой причине (точная причина очень важна, потому что по типу причины определяем, что за результат показывать). В данном случае, не так важно, что показали клиенту, так как основная идея тут – померить резолверы.
4. 17th March 2019, 15:06 // Александр Венедюхин:
> Вообще, не проще ли просто в маршрутизатор на openwrt (или подобном) поставить dnscrypt
Дело в том, что DNSCrypt не решает тех проблем, которые решает DNSSEC – DNSCrypt не защищает от подмены адресной информации где-то на пути до резолвера или в самом резолвере. Там есть только защита от вмешательства в канал на “последней миле”, от резолвера до клиента. То есть, тогда уж лучше держать свой резолвер с DNS-over-TLS и DNSSEC.
Написать комментарий