Ненадежный ответ DNS

Обновлено: 21.11.2024

Если у вас возникли проблемы с проверкой сертификата с помощью DNS, обратитесь к следующему руководству.

Первым шагом в устранении неполадок с DNS является проверка текущего состояния вашего домена с помощью следующих инструментов:

Темы

Подчеркивание запрещено поставщиком DNS

Если ваш провайдер DNS запрещает начальные символы подчеркивания в значениях CNAME, вы можете удалить подчеркивание из значения, предоставленного ACM, и проверить свой домен без него. Например, значение CNAME _x2.acm-validations.aws можно изменить на x2.acm-validations.aws для целей проверки. Однако параметр имени CNAME всегда должен начинаться с символа подчеркивания.

Для проверки домена можно использовать любое из значений в правой части таблицы ниже.

Конечный период по умолчанию, добавленный провайдером DNS

Некоторые провайдеры DNS по умолчанию добавляют завершающую точку к предоставленному вами значению CNAME. В результате самостоятельное добавление точки вызывает ошибку. Например, ".acm-validations.aws." отклоняется, а ".acm-validations.aws" принимается.

Проверка DNS на GoDaddy не удалась

Вы можете создать запись CNAME, совместимую с GoDaddy, усекая домен вершины (включая точку) в конце поля NAME следующим образом:

Устранение неполадок с доменом верхнего уровня .IO

Домен верхнего уровня .IO присвоен Британской территории в Индийском океане. В настоящее время реестр доменов не отображает вашу общедоступную информацию из базы данных WHOIS. Это верно независимо от того, включена ли у вас защита конфиденциальности для домена или отключена. При выполнении поиска в WHOIS возвращается только запутанная информация о регистраторе. Поэтому ACM не может отправить электронное письмо с подтверждением на следующие три зарегистрированных контактных адреса, которые обычно доступны в WHOIS.

Однако ACM отправляет электронное письмо с подтверждением на следующие пять общих системных адресов, где your_domain – это доменное имя, которое вы ввели при первоначальном запросе сертификата, а .io – домен верхнего уровня.

администратор@ваш_домен .io

hostmaster@ your_domain .io

postmaster@ваш_домен .io

веб-мастер@ваш_домен .io

admin@ ваш_домен .io

Чтобы получать письмо с подтверждением для домена .IO, убедитесь, что у вас включена одна из пяти предыдущих учетных записей электронной почты. В противном случае вы не получите подтверждение по электронной почте и вам не будет выдан сертификат ACM.

Мы рекомендуем использовать проверку DNS, а не проверку электронной почты. Дополнительные сведения см. в разделе Проверка DNS.

Консоль ACM не отображает кнопку «Создать запись в Route 53»

Если вы выберете Amazon Route 53 в качестве поставщика DNS, AWS Certificate Manager сможет напрямую взаимодействовать с ним, чтобы подтвердить право собственности на ваш домен. В некоторых случаях кнопка Создать запись в Route 53 на консоли может быть недоступна, когда вы этого ожидаете. В этом случае проверьте следующие возможные причины.

На странице подтверждения вы не нажали стрелку вниз рядом со своим доменным именем.

Вы не используете Route 53 в качестве DNS-провайдера.

Вы вошли в ACM и Route 53 под разными учетными записями.

У вас недостаточно прав IAM для создания записей в зоне, размещенной на Route 53.

Вы или кто-то другой уже подтвердил домен.

Домен не является общедоступным.

Проверка Route 53 не проходит проверку на частных (ненадежных) доменах

Во время проверки DNS ACM ищет запись CNAME в общедоступной зоне. Если он не находит его, время ожидания истекает через 72 часа со статусом Проверка истекла. Вы не можете использовать его для размещения DNS-записей для частных доменов, включая ресурсы в зоне размещения Amazon VPCprivate, ненадежные домены в вашей частной PKI и самозаверяющие сертификаты.

AWS предоставляет поддержку публично ненадежным доменам через службу частного ЦС ACM.

Сбой проверки DNS-сервера в VPN

Если вы обнаружите DNS-сервер в VPN, а ACM не сможет проверить сертификат для него, проверьте, является ли сервер общедоступным. Выпуск общедоступного сертификата с использованием проверки DNS ACM требует, чтобы записи домена разрешались через общедоступный Интернет.

В этой статье представлено решение проблемы, связанной с уязвимостью DNS-сервера к атакам с отслеживанием кэша DNS-сервера.

Применимо к: Windows Server 2012 R2
Исходный номер базы знаний: 2678371

Симптомы

Отслеживание кеша DNS — это когда кто-то запрашивает DNS-сервер, чтобы узнать (отслеживать), есть ли на DNS-сервере кэшированная запись DNS, и, таким образом, сделать вывод о том, что владелец DNS-сервера (или его пользователи) недавно посетил определенный сайт.
Это может привести к раскрытию информации о владельце DNS-сервера, например о поставщике, банке, поставщике услуг и т. д., которым он пользуется. Особенно, если это подтверждается (отслеживается) несколько раз за период.
Этот метод можно использовать даже для сбора статистической информации — например, в какое время владелец DNS-сервера обычно получает доступ к своему сетевому банку и т. д. Оставшееся значение TTL кэшированной записи DNS может предоставить очень точные данные для этого.

Отслеживание кеша DNS возможно, даже если сервер DNS не настроен на рекурсивное разрешение для третьих сторон, если он также предоставляет записи из кеша третьим сторонам.

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

Как только такой отчет об уязвимости отслеживания кеша гласит:

Причина

Об этой ошибке обычно сообщают серверы DNS, использующие рекурсию.

Разрешение

Нет исправления кода, так как это выбор конфигурации.

Есть три варианта:

Оставьте рекурсию включенной, если DNS-сервер остается в корпоративной сети, к которой не могут получить доступ ненадежные клиенты

Не разрешать публичный доступ к DNS-серверам, выполняющим рекурсию

Подробнее

По умолчанию DNS-серверы Microsoft разрешают рекурсию.

Рекурсия имен может быть отключена глобально на сервере Microsoft DNS, но не может быть отключена для каждого клиента или интерфейса.

Большинство DNS-серверов Microsoft устанавливаются вместе с ролью сервера контроллера домена. Такие серверы обычно размещают зоны и разрешают DNS-имена для устройств | устройства, рядовые клиенты, рядовые серверы и контроллеры домена в лесу Active Directory, но могут также разрешать имена для более крупных частей корпоративной сети. Поскольку DNS-серверы Microsoft обычно развертываются за брандмауэрами в корпоративных сетях, они недоступны для ненадежных клиентов. Администраторы серверов с этим параметром должны решить, нужно ли отключать или ограничивать рекурсию DNS.

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

Решение об отключении рекурсии (или нет) должно приниматься в зависимости от роли, которую DNS-сервер должен выполнять в рамках развертывания. Если сервер предназначен для рекурсии имен для своих клиентов, рекурсия не может быть отключена. Если сервер предназначен для возврата данных только из локальных зон и никогда не предназначен для рекурсии или пересылки для клиентов, рекурсия может быть отключена.

Вы можете использовать этот раздел, чтобы узнать, как распределять трафик приложения между различными географически распределенными экземплярами приложения с помощью политик DNS, основанных на времени суток.

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

Пример интеллектуальных ответов DNS в зависимости от времени суток

Ниже приведен пример использования политики DNS для балансировки трафика приложений в зависимости от времени суток.

Contoso Gift Services анализирует сайт и обнаруживает, что каждый вечер между 18:00 и 21:00 по местному времени наблюдается всплеск трафика на веб-серверы. Веб-серверы не могут масштабироваться для обработки возросшего трафика в часы пик, что приводит к отказу в обслуживании клиентов. Одинаковая перегрузка трафиком в часы пик происходит как в европейских, так и в американских центрах обработки данных. В другое время суток серверы обрабатывают объемы трафика, которые значительно ниже их максимальных возможностей.

На следующем рисунке показан этот сценарий.

Как работают интеллектуальные ответы DNS на основе времени суток

Если для DNS-сервера настроена политика DNS для времени суток, между 18:00 и 21:00 в каждом географическом местоположении DNS-сервер выполняет следующие действия.

Отвечает на первые четыре полученных запроса IP-адресом веб-сервера в локальном центре обработки данных.
Отвечает на пятый полученный запрос IP-адресом веб-сервера в удаленном центре обработки данных.

Это поведение, основанное на политике, разгружает двадцать процентов нагрузки трафика локального веб-сервера на удаленный веб-сервер, снижая нагрузку на локальный сервер приложений и повышая производительность сайта для клиентов.

В нерабочее время DNS-серверы выполняют обычное управление трафиком на основе геолокации.Кроме того, DNS-клиенты, отправляющие запросы из мест, отличных от Северной Америки или Европы, распределяют нагрузку DNS-сервера по трафику между центрами обработки данных в Сиэтле и Дублине.

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

Дополнительную информацию о типах политик и критериях см. в разделе Обзор политик DNS.

Как настроить политику DNS для интеллектуальных ответов DNS в зависимости от времени суток

Чтобы настроить политику DNS для балансировки нагрузки приложений в зависимости от времени суток, необходимо выполнить следующие шаги.

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

В следующих разделах приведены подробные инструкции по настройке.

В следующих разделах приведены примеры команд Windows PowerShell, которые содержат примеры значений для многих параметров. Прежде чем запускать эти команды, убедитесь, что вы заменили примеры значений в этих командах значениями, подходящими для вашего развертывания.

Создайте подсети DNS-клиента

Первый шаг — определить подсети или пространство IP-адресов регионов, для которых вы хотите перенаправить трафик. Например, если вы хотите перенаправить трафик в США и Европу, вам необходимо определить подсети или пространства IP-адресов этих регионов.

Эту информацию можно получить из карт Geo-IP. На основе этих распределений Geo-IP необходимо создать «Подсети DNS-клиентов». Подсеть DNS-клиента — это логическая группа подсетей IPv4 или IPv6, из которых запросы отправляются на DNS-сервер.

Вы можете использовать следующие команды Windows PowerShell для создания подсетей DNS-клиентов.

Создайте области действия зоны

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

Область зоны — это уникальный экземпляр зоны. Зона DNS может иметь несколько областей зоны, каждая из которых содержит собственный набор записей DNS. Одна и та же запись может присутствовать в нескольких областях, с разными IP-адресами или с одними и теми же IP-адресами.

По умолчанию область зоны существует в зонах DNS. Эта область зоны имеет то же имя, что и зона, и устаревшие операции DNS работают в этой области.

Для создания областей зоны можно использовать следующие команды Windows PowerShell.

Добавить записи в области действия зоны

Теперь вы должны добавить записи, представляющие хост веб-сервера, в две области зоны.

Для добавления записей в области зоны можно использовать следующие команды Windows PowerShell.

Параметр ZoneScope не включается при добавлении записи в область действия по умолчанию. Это аналогично добавлению записей в стандартную зону DNS.

Создайте политики DNS

После создания подсетей, разделов (областей зоны) и добавления записей необходимо создать политики, связывающие подсети и разделы, чтобы при поступлении запроса из источника в одной из подсетей DNS-клиента , ответ на запрос возвращается из правильной области действия зоны. Для сопоставления области зоны по умолчанию не требуется никаких политик.

После настройки этих политик DNS поведение DNS-сервера будет следующим:

Европейские DNS-клиенты получают IP-адрес веб-сервера в центре обработки данных в Дублине в своем ответе на DNS-запрос.
Американские DNS-клиенты получают IP-адрес веб-сервера в центре обработки данных в Сиэтле в своем ответе на DNS-запрос.
С 18:00 до 21:00 в Дублине 20 % запросов от европейских клиентов получают IP-адрес веб-сервера в центре обработки данных в Сиэтле в своем ответе на DNS-запрос.
С 18:00 до 21:00 в Сиэтле 20 % запросов от американских клиентов получают IP-адрес веб-сервера в центре обработки данных в Дублине в ответе на запрос DNS.
Половина запросов из остального мира получает IP-адрес центра обработки данных в Сиэтле, а другая половина — IP-адрес центра обработки данных в Дублине.

Вы можете использовать следующие команды Windows PowerShell для создания политики DNS, которая связывает подсети DNS-клиента и области зоны.

В этом примере DNS-сервер находится в часовом поясе по Гринвичу, поэтому часы пиковой нагрузки должны быть выражены в эквивалентном времени по Гринвичу.

Теперь DNS-сервер настроен с необходимыми политиками DNS для перенаправления трафика в зависимости от географического положения и времени суток.

Когда DNS-сервер получает запросы на разрешение имен, DNS-сервер оценивает поля в DNS-запросе в соответствии с настроенными политиками DNS. Если исходный IP-адрес в запросе разрешения имени соответствует какой-либо из политик, для ответа на запрос используется область связанной зоны, а пользователь направляется к ресурсу, который географически ближе всего к нему.

Вы можете создать тысячи политик DNS в соответствии с вашими требованиями к управлению трафиком, и все новые политики применяются динамически — без перезапуска DNS-сервера — к входящим запросам.

DNS остается важной частью компьютерных сетей. Фундамент DNS был заложен в 1983 году Полом Мокапетрисом, тогда работавшим в Университете Южной Калифорнии, во времена ARPAnet, исследовательского проекта Министерства обороны США, который соединил компьютеры в небольшом количестве университетов и исследовательских институтов, что в конечном итоге привело к Интернету. Система работает как служба 411 телефонной компании: по имени она ищет номера, которые приведут к носителю этого имени.

DNS никогда не разрабатывался как очень безопасный протокол, поэтому он часто используется злоумышленниками. Существует два способа взлома DNS: с помощью протокольных атак (атак, основанных на том, как DNS на самом деле работает) или с помощью серверных атак (атак, основанных на ошибках или недостатках программ или машин, на которых запущены службы DNS).

Одной из самых печально известных атак на протоколы была вредоносная программа DNSChanger. Обычно это работало путем изменения настроек DNS-сервера на зараженных компьютерах, что позволяло злоумышленникам направлять интернет-трафик через вредоносные серверы и перехватывать конфиденциальную информацию. Был также аналогичный вариант, предназначенный для компьютеров Apple Mac, получивший название OSX/MaMi, неподписанный 64-разрядный исполняемый файл Mach-O.

В обоих этих случаях злоумышленники изменили ваш DNS-сервер с 8.8.8.8 (Google), например, на один из своих собственных DNS-серверов. Большинство ваших DNS-запросов будут обработаны правильно, и вы получите правильные IP-адреса. Однако для некоторых сайтов (например, банковских) злоумышленники направят вас на смоделированный веб-сайт, который выглядит как действительный банковский. Ваши данные для входа будут перехвачены, как только вы начнете взаимодействовать с сайтом, а затем использованы для кражи ваших денег.

Обнаружение несанкционированного использования DNS-сервера

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

Такой журнал аудита DNS также даст вам данные, необходимые для расследования других проблем с DNS, таких как отравление кеша.

Как генерировать оповещения, если устройство использует неавторизованный DNS-сервер

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

192.168.127.22 (размещено внутри сети)
8.8.8.8 (google1)
8.8.4.4 (google2)

Затем можно использовать параметр конфигурации оповещений, чтобы создать правило оповещений DNS, которое будет срабатывать при обнаружении запросов к другим серверам. После срабатывания оповещения о несанкционированном DNS-сервере инструмент NTA захватит определенные метаданные DNS, такие как IP-адреса источника и получателя, страну, в которой зарегистрирован DNS-сервер, и запрошенные доменные имена.

Эти оповещения также можно экспортировать в виде SYSLOG, чтобы они могли обрабатываться блокирующим устройством, таким как брандмауэр или система контроля доступа к сети (NAC).

Как отслеживать DNS-трафик

Один из лучших способов мониторинга DNS-трафика — портировать зеркальный трафик, входящий и исходящий с ваших локальных DNS-серверов, а также весь интернет-трафик. Мониторинг интернет-трафика имеет решающее значение, так как вы можете подключаться к устройствам, использующим внешние DNS-серверы, поэтому отслеживать сетевой трафик в вашей сети очень просто. Большинство управляемых коммутаторов поддерживают SPAN или зеркальные порты. Если у вас есть коммутатор, который не имеет параметров мониторинга трафика, существует множество альтернатив для портов SPAN. В приведенном ниже видео показаны шаги, необходимые для мониторинга интернет-трафика, и вам следует расширить его, чтобы также отслеживать локальные DNS-серверы.

Статус этой заметки

Этот Интернет-проект представлен в полном соответствии с положениями BCP 78 и BCP 79.¶

Интернет-черновики — это проекты документов, действительные не более шести месяцев, и в любое время они могут быть обновлены, заменены или устаревшими другими документами. Неуместно использовать Internet-Drafts в качестве справочного материала или цитировать их иначе, чем как «незавершенную работу».¶

Срок действия этого интернет-драфта истекает 16 апреля 2022 г.¶

Уведомление об авторских правах

Содержание

1. Введение

DNS-фильтры развертываются по разным причинам, включая безопасность конечных точек, родительскую фильтрацию и фильтрацию, требуемую правоохранительными органами. Сетевые решения безопасности, такие как брандмауэры и системы предотвращения вторжений (IPS), полагаются на проверку сетевого трафика для реализации политик безопасности на основе периметра и действуют путем фильтрации ответов DNS. Дома фильтрация DNS используется по тем же причинам, что и выше, и дополнительно для родительского контроля. Интернет-провайдеры обычно блокируют доступ к некоторым доменам DNS из-за требования, наложенного внешним субъектом (например, правоохранительным органом), которое также выполняется с использованием фильтрации контента на основе DNS.¶

Пользователи служб DNS, выполняющих фильтрацию, могут захотеть получить дополнительную информацию о такой фильтрации, чтобы решить проблемы с фильтром, например, чтобы связаться с администратором, чтобы внести в белый список домен, который был ошибочно отфильтрован, или понять, почему конкретный домен был отфильтровано. С помощью этой информации пользователь может выбрать другую сеть, создать заявку на устранение неполадок у администратора DNS, чтобы устранить ошибочную фильтрацию, зарегистрировать информацию или выполнить другие действия.¶

Ответы DNS можно отфильтровать, отправив фиктивный (также называемый «поддельным») ответ A или AAAA, ошибку NXDOMAIN или пустой ответ или расширенный код ошибки DNS (EDE), определенный в [RFC8914] . Каждый из этих методов имеет свои преимущества и недостатки, которые обсуждаются ниже:¶

Однако настройка локального корневого сертификата на конечных точках нецелесообразна в некоторых развертываниях, например в домашних сетях, школах, малых и домашних офисах (SOHO) и малых/средних предприятиях (SME). В этих случаях типичное поведение заключается в том, что поддельный ответ DNS направляет пользователя на сервер, размещенный для отображения страницы блокировки, которая разрывает соединение TLS. При просмотре веб-страниц это приводит к сообщению об ошибке сертификата HTTPS, указывающему, что безопасное соединение не может быть установлено, что не дает конечному пользователю никакой информации о причине ошибки. Типичные ошибки: «Сертификат безопасности, представленный этим веб-сайтом, не был выдан доверенным центром сертификации» (Internet Explorer/Edge), «Сертификат безопасности сайта не является доверенным» (Chrome), «Это соединение не является доверенным» (Firefox ), «Safari не может подтвердить подлинность веб-сайта. " (Safari на MacOS)".¶

Для обоих механизмов фильтрации DNS, описанных выше, DNS-сервер может возвращать расширенные коды ошибок: Blocked, Censored, Filtered или Forged Answer, определенные в разделе 4 [RFC8914]. Однако эти коды только объясняют, что фильтрация имела место, но не содержат деталей, позволяющих пользователю диагностировать ошибочную фильтрацию.¶

Независимо от того, какой тип ответа генерируется (поддельные IP-адреса, NXDOMAIN или пустой ответ, даже с расширенным кодом ошибки), у пользователя, инициировавшего запрос DNS, мало шансов понять, какой объект отфильтровал запрос, как сообщить об ошибке в фильтре, или почему сущность вообще его отфильтровала. В этом документе описывается механизм предоставления такой информации.¶

В этом документе описывается протокол, содержащий анализируемые данные в новом коде опции EDNS(0) [RFC6891].¶

Клиенты указывают, что они поддерживают эту спецификацию в своем DNS-запросе, чтобы DNS-сервер мог соответствующим образом адаптировать свой DNS-ответ. Информация, возвращаемая в ответе DNS, позволяет информировать о фильтрации комбинацию безголовых устройств (т. е. устройств без дисплея или других средств связи с человеком), операционных систем и веб-браузеров. Эта возвращенная информация может быть зарегистрирована и/или отображена пользователю в зависимости от возможностей пользовательского интерфейса аппаратного и программного обеспечения клиента.¶

Этот документ не рекомендует фильтрацию DNS, но предоставляет механизм для большей прозрачности, чтобы объяснить пользователям, почему фильтруются некоторые DNS-запросы.¶

2. Терминология

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ», и «НЕОБЯЗАТЕЛЬНЫЙ» в этом документе следует интерпретировать, как описано в BCP 14 [RFC2119] [RFC8174], когда и только тогда, когда они появляются заглавными буквами, как показано здесь¶

В этом документе используются термины, определенные в терминологии DNS [RFC8499].¶

"Запрашивающая сторона" относится к стороне, которая отправляет запрос. «Ответчик» относится к полномочному, рекурсивному преобразователю или другому компоненту DNS, который отвечает на вопросы.Здесь используется другая терминология, определенная в документах RFC, цитируемых в этом документе.¶

3. Код опции структурированной ошибки EDNS(0)

В этом документе определяется новый код опции EDNS(0) [RFC6891] (OPT), который включает в себя информацию JSON, предоставляющую информацию в ответе DNS, описывающую фильтрацию, которая произошла для этого запроса, как показано на рисунке 1.¶

Значение этого кода опции EDNS(0) (OPT) — TBA-BY-IANA.¶

Описание полей выглядит следующим образом:¶

STRUCTURED-ERROR-LENGTH: Два октета, содержащие длину STRUCTURED-ERROR-JSON, в октетах. НЕ ДОЛЖЕН быть установлен на 0.¶ STRUCTURED-ERROR-JSON: JSON, содержащий информацию о фильтрации DNS, закодированную в JSON, определенную в Разделе 4.¶

4. Структурированный JSON

STRUCTURED-ERROR-JSON содержит следующие имена JSON:¶

c: (жалоба) частичный URI для дальнейшей диагностики и, возможно, сообщения о неправильно классифицированной фильтрации DNS. Значение преобразуется в расширенный абсолютный URI. Это поле является необязательным, но обратите внимание, что его отсутствие по-прежнему позволяет сформировать URI.¶ d: (домен) Содержит доменное имя зашифрованного DNS-сервера. Это используется для создания расширенных URI для полей «c» и «r», а также для обнаружения нежелательной пересылки параметров EDNS(0). Это поле является обязательным.¶ j: (обоснование) текстовое обоснование для данной конкретной фильтрации DNS. Это поле обязательно для заполнения.¶ o: (organization) удобное для человека название организации, отфильтровавшей данный конкретный DNS-запрос. Это поле является необязательным.¶ r: (постановление) частичный URI для получения общедоступного или частного правила, закона или постановления, описывающего причину использования этого DNS-фильтра. Это может указывать на трудовое соглашение (для предприятия, выполняющего фильтрацию) или постановление национального правительства (для интернет-провайдера, выполняющего фильтрацию). Это поле является необязательным, но обратите внимание, что его отсутствие по-прежнему позволяет формировать URI.¶

Чтобы уменьшить нагрузку на пакет, сгенерированный JSON ДОЛЖЕН быть как можно короче: короткие доменные имена, краткий текст в значениях для имен "j" и "o" и минимизированный JSON (то есть без пробелов или разрывов строк между элементы JSON).¶

Данные JSON могут быть проанализированы для отображения пользователю, зарегистрированы или использованы иным образом, чтобы помочь конечному пользователю или ИТ-персоналу в устранении неполадок и диагностике причины DNS-фильтрации.¶

5. Операция протокола

5.1. Клиент создает запрос

При создании DNS-запроса клиент ДОЛЖЕН включать параметр Structured Error EDNS(0) при использовании зашифрованного DNS, чтобы DNS-сервер знал, что клиент соответствует этой спецификации.¶

5.2. Сервер генерирует ответ

Когда DNS-сервер фильтрует свой ответ DNS на запрос записи A или AAAA, ответ DNS МОЖЕТ содержать пустой ответ, NXDOMAIN, или поддельный ответ A или AAAA, по желанию DNS-сервера. Кроме того, если запрос содержит параметр Structured Error EDNS(0), DNS-сервер МОЖЕТ вернуть более подробную информацию в формате STRUCTURED-ERROR-JSON, как описано ниже.¶

Со временем доменное имя может фильтроваться, затем не фильтроваться, а затем снова фильтроваться. Кроме того, у пользователя могут пройти минуты или даже дни, прежде чем он рассмотрит отфильтрованный DNS-запрос. Таким образом, РЕКОМЕНДУЕТСЯ включать в URI жалобы достаточно подробностей, чтобы определить состояние фильтрации, когда произошла фильтрация DNS. Если и как это закодировано в URI жалобы, это решение реализации.¶

5.3. Ответ обработки клиента

При получении ответа DNS выполняются следующие действия, характерные для параметра Structured Error EDNS(0), в произвольном порядке:¶

Запрашивающая сторона ДОЛЖНА проверить, что ответ был получен по зашифрованному каналу DNS. В противном случае запрашивающая сторона ДОЛЖНА отбросить любую возвращенную опцию Structured Error EDNS(0).¶
Если ответ DNS содержит более одной опции структурированной ошибки EDNS(0), отправитель запроса ДОЛЖЕН отменить все опции структурированной ошибки ENDS(0).¶
Ответ DNS ДОЛЖЕН также содержать расширенный код ошибки «Цензурировано», «Заблокировано», «Отфильтровано» или «Подделано», в противном случае параметр структурированной ошибки EDNS(0) отбрасывается.¶
Если какое-либо из обязательных имен JSON "d" и "j" отсутствует или имеет пустые значения в параметре Structured Error EDNS(0), этот параметр отбрасывается.¶
Запрашивающая сторона расширяет значения в "c" и "r", добавляя к двум значениям префикс "https://" и значение имени "d". Затем запрашивающая сторона дополнительно расширяет каждый из URI «c» и «r», добавляя два параметра запроса URL: «type», указывающий имя запрошенного типа записи ресурса DNS, и «name», указывающий имя запрошенной записи ресурса DNS. ¶

Обратите внимание, что париальное значение URI в "c" или "r" уже будет содержать ноль или более параметров запроса, поэтому реализации должны заменить "?" и "&" соответственно.¶

Если DNS-клиент включил уступающий профиль конфиденциальности (раздел 5 [RFC8310]) для DoT, DNS-клиент либо переключится на зашифрованное соединение без проверки подлинности DNS-сервера, предоставляемого локальной сетью, либо переключится на незашифрованный текст DNS. и не может обмениваться зашифрованными сообщениями DNS. Оба этих резервных механизма отрицательно сказываются на безопасности и конфиденциальности. Если DNS-клиент включил оппортунистический профиль конфиденциальности для DoT, DNS-клиент ДОЛЖЕН игнорировать ответы с опцией структурированной ошибки DNS EDNS(0), но ДОЛЖЕН обрабатывать другие части ответа.¶
Если DNS-клиент включил строгий профиль конфиденциальности (раздел 5 [RFC8310]) для DoT, DNS-клиенту требуется зашифрованное соединение и успешная проверка подлинности DNS-сервера; это снижает как пассивное прослушивание, так и перенаправление клиентов (за счет отсутствия службы DNS, если зашифрованное соединение с проверкой подлинности недоступно). Если DNS-клиент включил строгий профиль конфиденциальности для DoT, клиент МОЖЕТ обработать опцию Structured DNS Error EDNS(0) ответа DNS. Обратите внимание, что строгие и оппортунистические профили конфиденциальности, определенные в [RFC8310], применяются только к DoT; для DoH такого различия не проводилось.¶
Если DNS-клиент определяет, что зашифрованный DNS-сервер не предлагает услугу фильтрации DNS, он ДОЛЖЕН отклонить параметр Structured Error EDNS(0). Например, DNS-клиент может узнать, выполняет ли зашифрованный преобразователь DNS фильтрацию содержимого на основе DNS или нет, получая информацию о преобразователе с помощью метода, определенного в [I-D.reddy-add-resolver-info].¶
Предполагается, что серверы пересылки DNS (или прокси-серверы DNS) распространяют неизвестные параметры EDNS(0) (разделы 4.1 и 4.4.1 [RFC5625]), что означает, что параметр структурированной ошибки EDNS(0) может распространяться таким сервером DNS. сервер. Чтобы обнаружить этот сценарий, DNS-клиент ДОЛЖЕН проверить, что доменное имя в значении «d» структурированной ошибки совпадает с доменным именем зашифрованного преобразователя DNS. Если это совпадение не удается, DNS-клиент ДОЛЖЕН игнорировать параметр Structured Error EDNS(0) в ответе.¶

6. Примеры

На рис. 3 тот же контент показан в уменьшенном формате JSON (без пробелов и пустых строк) с переносом строк '\' в соответствии с [RFC8792].¶

После получения два частичных URI ("c" и "r") преобразуются в полностью сформированные URI. Класс, тип и имя извлекаются из ответа DNS (соответствующего соответствующему запросу), так что полностью сформированный URI «c» становится «https://ns.example.net?time=1621902483&type=a&name=example». org», а URI «r» становится «https://ns.example.net?country=atlantis&type=a&name=example.org».¶

7. Вопросы безопасности

Соображения безопасности, изложенные в разделе 6 [RFC8914], относятся к этому документу.¶

Чтобы свести к минимуму влияние активных атак на канал DNS, клиент проверяет ответ, как описано в Разделе 5.3.¶

При отображении букв "o" и "j" в произвольной форме браузеру НЕ СЛЕДУЕТ превращать какие-либо из этих элементов в интерактивные ссылки.¶

Несмотря на то, что значение "d" проверено, злоумышленник, который может внедрить параметр Structured Error EDNS(0), чтобы прокси-сервер DNS или сервер пересылки DNS, не зная об этом параметре, переслал его и прошел описанные проверки проверки. в разделе 5.3. Это означает, что злоумышленник может контролировать другие поля JSON. Поля «j» и «o», возможно, наиболее интересны злоумышленнику для изменения в гнусных целях, потому что поле «d» должно соответствовать зашифрованному имени DNS-сервера и расширенным URI из «c» и « r" укажет на преобразователь DNS, не находящийся под контролем злоумышленника.¶

Авторы ожидают, что усовершенствования [I-D.reddy-add-resolver-info] уменьшат или устранят проблемы, описанные в предыдущем абзаце.¶

8. Соображения IANA

Этот документ требует, чтобы IANA присвоило значение кода опции DNS EDNS0 (OPT) в диапазоне экспертной проверки под названием «Ошибка структурированной DNS».¶

Этот документ требует от IANA зарегистрировать тип мультимедиа «application/json+structured-dns-error» в реестре «Типы мультимедиа» [IANA-MediaTypes] . Эта регистрация соответствует процедурам, указанным в [RFC6838]:¶

9. Изменения

Этот раздел следует удалить перед публикацией в виде RFC.¶

9.1. Изменяется с 00 на 01

удалена поддержка нескольких ответственных сторон¶
односимвольные имена JSON для минимизации длины JSON¶
частичный URI, отправленный в именах "c" и "r", в сочетании с именем "d", отправленным в JSON, чтобы свести к минимуму поверхность атаки и минимизировать длину JSON¶
Текст EDNS(0) о предотвращении подделки, некоторые вопросы безопасности и некоторые другие тексты перемещены из [страницы I-D.reddy-dnsop-error-page] в этот документ¶

10. Ссылки

10.1. Нормативные ссылки

[RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания уровней требований», BCP 14, RFC 2119, DOI 10.17487/RFC2119, март 1997 г., . [RFC6838] Фрид, Н., Кленсин Дж. и Т. Хансен, «Спецификации типов носителей и процедуры регистрации», BCP 13, RFC 6838, DOI 10.17487/RFC6838, январь 2013 г., . [RFC6891] Дамас Дж., Графф М. и П. Викси, «Механизмы расширения для DNS (EDNS(0))», STD 75, RFC 6891, DOI 10.17487/RFC6891, апрель 2013 г., . [RFC8174] Лейба, Б., «Неоднозначность прописных и строчных букв в ключевых словах RFC 2119», BCP 14, RFC 8174, DOI 10.17487/RFC8174, май 2017 г., . [RFC8310] Дикинсон С., Гиллмор Д. и Т. Редди, «Профили использования DNS поверх TLS и DNS поверх DTLS», RFC 8310, DOI 10.17487/RFC8310, март 2018 г.,

Читайте также: