AdGuard DNS теперь поддерживает структурированные ошибки DNS. Что это значит

6 ноября 2024 г. время чтения: 7 мин

Релиз 2.10 по масштабу может сравниться с внедрением поддержки DNS-over-QUIC — AdGuard DNS вновь стал первым в мире публичным DNS-резолвером, поддерживающим нововведение ещё до того, как оно стало официальным стандартом. На этот раз — структурированные ошибки DNS (Structured DNS Errors, SDE).

Дальше мы подробно распишем, что это такое и почему это так важно. А если у вас сейчас мало времени на чтение, вот кратко:

Если сайт блокируется на уровне DNS, при переходе на него пользователь увидит ошибку «Страница не найдена» или «Нет подключения к интернету». Это не объясняет причину блокировки.
Чтобы это исправить, DNS-серверы могли бы перенаправлять пользователя на свою страницу с объяснением. Но в случае HTTPS-сайтов (которых большинство) придётся устанавливать отдельный сертификат.
Есть более простое решение: структурированные ошибки DNS (SDE). Они позволяют передать дополнительную информацию в DNS-ответе (причину блокировки, кто ответственный и куда обратиться), чтобы браузер смог считать её и передать пользователю. Это существенно повысит прозрачность коммуникации.
Чтобы система функционировала, в первую очередь нужно, чтобы браузеры начали поддерживать SDE. Именно к этому мы призываем.

Что такое структурированные ошибки DNS: подробно

Фильтрация на уровне DNS очень популярна. Только у AdGuard DNS больше 100 миллионов пользователей. Пользователи используют DNS-фильтрацию, чтобы блокировать рекламу и трекеры или защитить детей. Даже если пользователь не настраивал DNS самостоятельно, он всё равно сталкивается с DNS-фильтрацией — из-за политики государства или компании, в которой работает. Легко предположить, что пользователей, которые хотя бы раз сталкивались с сайтом, недоступным из-за DNS-фильтрации, почти столько же, сколько пользователей интернета.

Блокировка на уровне DNS блокирует домен целиком. Пользователь пытается перейти на https://example.com, браузер делает DNS-запрос. DNS-сервер отвечает, что домен example.com заблокирован, и браузер говорит пользователю: страница не найдена или вы не подключены к интернету.

Ошибка «Страница не найдена»

Если пользователь сам не создал правило блокировки, он может не понять, почему доступ к сайту ограничен. Он подумает:

Что-то не так. Может, перезапустить страницу?
Не сработало. Может, интернет отключился?
С интернетом всё в порядке. Может, сайт заблокирован? Но почему?
Наверное, это мой DNS сломался, надо написать жалобу.

А дело в недостатке коммуникации между DNS-сервисом и пользователем. DNS-сервисы могут и хотят это исправить — например, сделать редирект на свою собственную страницу с объяснением причин блокировки, чтобы пользователь знал, что произошло и куда он может обратиться.

Может, так и сделать?

Но есть загвоздка:

Если это HTTP-сайт, то есть соединение не зашифровано, то DNS-сервер может спокойно перенаправить на собственную страницу, но тоже не зашифрованную.
Если это HTTPS-сайт, то есть соединение зашифровано, то браузер должен выполнить проверку подлинности сертификата. Браузер ожидает увидеть сертификат для https://example.com — поэтому при редиректе на отдельную страницу AdGuard DNS браузер вернёт ошибку валидации сертификата.

Ошибка сертификата

Чтобы это решить, можно установить специальный сертификат на устройство. Но это не всегда возможно и не всегда безопасно. При этом есть куда более простой путь — отправлять больше информации в DNS-ответе.

Для этого в 2020 году был принят стандарт для так называемых Extended DNS Errors — расширенных ошибок DNS. Это DNS-ответы, которые могут включать в себя не только код ошибки, но и поле EXTRA-TEXT с более подробной информацией. А также есть интернет-драфт, где описаны Structured DNS Errors — структурированные ошибки DNS. В поле EXTRA-TEXT предлагается добавлять файлы I-JSON (это более строгий формат JSON), которые браузеры могли бы легко считать и отобразить в понятном для пользователя виде.

Что будет содержаться в этих I-JSON-файлах:

Причина блокировки
Контактные данные, к кому можно обратиться, если страница заблокирована по ошибке
Какая организация отвечает за DNS-фильтрацию в конкретном случае (опционально)
Другая опциональная информация

И это правда удобно. Такое поведение не только повышает прозрачность коммуникации между DNS-сервисами и пользователями, но и заботится об их безопасности: если они будут понимать, в чём причина блокировки, меньше шансов, что они плюнут и навсегда переключатся на незашифрованный системный сервер.

Что нужно, чтобы реализовать Extended DNS Errors и Structured DNS Errors

Нужно, чтобы браузеры начали их поддерживать. Ведь именно они отвечают за то, какую информацию в итоге увидит пользователь — просто ошибку подключения или подробное объяснение, почему заблокирован сайт и что делать дальше.

Поэтому здесь мы призываем представителей браузеров добавить поддержку RFC 8914, а в идеале — с дополнением. Это изменение поможет сделать интернет прозрачнее и дружелюбнее для миллиардов людей.

Как это выглядит в AdGuard DNS

Мы создали демо-расширение, чтобы показать, как могли бы работать структурированные ошибки DNS, если бы браузеры их поддерживали. Если вы со включённым расширением перейдёте на заблокированный сайт, оно считает информацию из SDE и покажет вот такую страницу с объяснением. Правда, это куда понятнее, чем предыдущие примеры?

Страница с объяснением

Если вы хотите посмотреть, как это выглядит на уровне DNS, вы можете использовать команду dig и найти EDE в выводе.

% dig @94.140.14.14 'ad.doubleclick.net' A IN +ednsopt=15:0000

...

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 17 (Filtered): ({"j":"Filtered by AdGuard DNS","o":"AdGuard DNS","c":["mailto:support@adguard-dns.io"]})
;; QUESTION SECTION:
;ad.doubleclick.net.		IN	A

...

Найти расширение можно в магазине Chrome или на GitHub.

Другие улучшения: более персонализированная работа с пользователями и организациями

Среди нашей аудитории — как пользователи, которые настраивают DNS для дома, так и крупные организации. У них разные запросы и разный пользовательский опыт: одним нужно подключить 10 устройств, зато они готовы сделать это вручную; другим нужно подключить 1000 устройств и желательно автоматически. Чтобы лучше знать, что конкретно нужно каждому пользователю, мы добавили онбординг — небольшой опросник о целях и ожидаемом количестве устройств.

Онбординг