Техническое: эксперимент с резолверами и 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/
Похожие записки:
- Статья про DNS-измерения в Сети (2020)
- Реплика: очередное предостережение и угрозы ИИ
- Ретроспектива заметок: июль 2012 года
- Дирижабли в 2008 году
- Десятилетие DNSSEC в российских доменах
- Удостоверяющий центр TLS ТЦИ
- Экспериментальный сервер TLS 1.3: замена сертификатов
- HTTPS-запись в DNS для dxdt.ru
- Техническое: poison-расширение и SCT-метки в Certificate Transparency
- "Двухфакторная" аутентификация и Google Authenticator
- Трафик на тестовом сервере TLS 1.3 и ESNI
Комментарии читателей блога: 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.
Написать комментарий