Dns через https или DNS через tls

Обновлено: 21.11.2024

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

Чтобы решить эти проблемы, Google Public DNS предлагает разрешение DNS через TCP-подключения с шифрованием TLS, как указано в RFC 7858. DNS-over-TLS повышает конфиденциальность и безопасность между клиентами и преобразователями. Это дополняет DNSSEC и защищает проверенные DNSSEC результаты от модификации или подделки на пути к клиенту.

Как это работает

Клиентская система может использовать DNS-over-TLS с одним из двух профилей: строгая или гибкая конфиденциальность. В профиле строгой конфиденциальности пользователь настраивает имя DNS-сервера (имя домена аутентификации в RFC 8310) для службы DNS-over-TLS, и клиент должен иметь возможность создавать безопасное соединение TLS на порту. 853 на DNS-сервер. Неспособность установить безопасное соединение является серьезной ошибкой и приведет к отключению службы DNS для клиента.

При использовании оппортунистического профиля конфиденциальности IP-адрес DNS-сервера может быть настроен непосредственно пользователем или получен из локальной сети (с использованием DHCP или каким-либо другим способом). Преобразователь клиента пытается установить безопасное соединение через порт 853 с указанным DNS-сервером. Если установлено безопасное соединение, это обеспечивает конфиденциальность запросов пользователя от пассивных наблюдателей на пути. Поскольку клиент не проверяет подлинность сервера, он не защищен от активного злоумышленника. Если клиент не может установить безопасное соединение через порт 853, он возвращается к обмену данными с DNS-сервером через стандартный порт DNS 53 через UDP или TCP без какой-либо безопасности или конфиденциальности. Использование Opportunistic Privacy предназначено для поддержки поэтапного развертывания повышенной конфиденциальности с целью повсеместного внедрения строгого профиля конфиденциальности.

При использовании строгого профиля конфиденциальности резолверы-заглушки устанавливают соединение DNS-over-TLS, выполнив следующие действия.

Преобразователю-заглушке настраивается имя преобразователя DNS-over-TLS dns.google .
Резолвер-заглушка получает IP-адрес(а) для dns.google с помощью локального резолвера DNS.
Преобразователь-заглушка устанавливает TCP-соединение с портом 853 по тому же IP-адресу.
Резолвер-заглушка инициирует рукопожатие TLS с резолвером Google Public DNS.
Общедоступный DNS-сервер Google возвращает свой сертификат TLS вместе с полной цепочкой сертификатов TLS вплоть до доверенного корневого сертификата.
Преобразователь-заглушка проверяет подлинность сервера на основе представленных сертификатов.
- Если удостоверение не может быть проверено, разрешение DNS-имени завершается сбоем, и тупиковый преобразователь возвращает ошибку.
После того, как TLS-соединение установлено, тупиковый преобразователь получает безопасный путь связи между общедоступным DNS-сервером Google.
Теперь резолвер-заглушка может отправлять DNS-запросы и получать ответы по соединению.

При использовании гибкого профиля конфиденциальности клиент сначала пытается создать безопасное TLS-соединение с сервером. Это делается аналогично предыдущему с одним важным отличием — клиент не выполняет проверку сертификата. Это означает, что личности сервера нельзя доверять. Если не удается установить TLS-подключение к серверу через порт 853, тупиковый преобразователь возвращается к обращению к DNS-серверу через порт 53.

Конфиденциальность

Наша политика конфиденциальности распространяется на службу DNS-over-TLS.

27 июня 2019 г. мы повторно включили клиентскую подсеть EDNS (ECS) для службы DNS-over-TLS. ECS был отключен при запуске службы.

Поддержка стандартов

Google Public DNS реализует DNS-over-TLS на основе RFC 7858. Кроме того, мы поддерживаем следующие рекомендации по предоставлению высококачественной службы DNS с малой задержкой.

Начать использовать

См. инструкции по настройке на устройстве с Android 9 (Pie) или более поздней версии.

DNS-over-TLS также поддерживается для службы Google Public DNS64 только для IPv6. Обратите внимание, что настраивать DNS64 для мобильного устройства, которое будет подключаться к нескольким сетям, не рекомендуется, поскольку DNS64 работает только при наличии IPv6.

Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

Хотя это и звучит как одно и то же, есть одно существенное различие, которое вызывает жаркие споры.

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

Итак, без лишних слов, давайте все обсудим…

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

Если вам когда-нибудь понадобится узнать IP-адрес посещаемого веб-сайта, это легко сделать как на Windows, так и на Mac. Пользователям Windows просто нужно ввести «cmd» в строку поиска и открыть командную строку, а затем ввести:

Для пользователей Apple это немного проще и немного элегантнее. В строке поиска вашего Mac введите «Сетевая утилита» и нажмите, чтобы открыть ее. Затем перейдите на вкладку Traceroute и введите имя домена в поле трассировки. Легко.

Исторически запросы DNS выполнялись с использованием протоколов UDP или TCP, то есть они отправлялись в виде открытого текста.

И как мы обсудим, это может быть проблемой.

Зачем нам нужно шифровать DNS-запросы?

Если вы живете в США, Великобритании или Австралии, как и большинство наших читателей, легко принять как должное права и свободы, которыми мы пользуемся. По большому счету, наши проблемы с конфиденциальностью довольно тривиальны. На прошлой неделе я узнал, что я был одним из тех 50 миллионов счастливчиков, чьи данные на Facebook были скомпрометированы.

И хотя это в высшей степени раздражает, мы бы насмешливо назвали это проблемой первого мира. Хотя есть несколько ужасающих исключений, худшее, что может случиться с большинством из нас, — это кража личных данных. И это не шутка, но и не угроза вашей жизни или свободе. В США, Великобритании и большей части западного мира нет ничего, кроме детской порнографии и снаффа.

Это не может быть менее верно для других частей мира. В Китае общеизвестно ограниченный доступ к Интернету (для которого Google в настоящее время разрабатывает подпольную поисковую систему с цензурой).

Россия, Северная Корея, Иран, Саудовская Аравия — и это лишь некоторые из крупных стран — входят в число десятков стран, которые ограничивают использование Интернета для своих граждан.

По данным Freedom House, менее четверти пользователей Интернета в мире проживают в странах, в которых Интернет считается бесплатным. Это бесплатно с точки зрения прав и свобод, а не цены. 36 % процентов интернет-пользователей живут в странах, где интернет полностью ограничен, а еще 28 % живут в странах, где интернет ограничен частично.

Черт возьми, пару недель назад во всей Эфиопии был отключен доступ к Интернету, чтобы попытаться подавить то, что в то время выглядело как потенциальный военный переворот.

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

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

Никто не спорит, что DNS-запросы не должны шифроваться, спор идет о том, как лучше это сделать.

Конечно, сам запрос — его содержимое или ответ — зашифрован. Таким образом, вы не будете знать, что запрашивается, но они будут знать, что вы используете DNS поверх TLS. И это как минимум вызовет подозрения. Это как взять пятое место в США.Это просто создает впечатление, что вам есть что скрывать, а во многих странах такое мнение о вас не очень хорошее.

Применение DNS через TLS

RFC 8484 — это кластерная утка для интернет-безопасности. Извините, что дождь на вашем параде. Заключенные захватили приют.

Лично в отделе уток я неравнодушен к Крякве, но, во всяком случае, оппозиция Викси делается не столько с точки зрения добросовестного правозащитника, сколько с точки зрения опытного ветерана службы безопасности. Те же самые недостатки прав человека, возможность идентифицировать запросы DoT — также благо для безопасности.

DoH – это первоклассный способ обхода корпоративных и других частных сетей. Но DNS является частью уровня управления, и сетевые операторы должны иметь возможность отслеживать и фильтровать его. Используйте DoT, а не DoH», — написала Викси в Твиттере.

Это хорошо с точки зрения прав человека и плохо с точки зрения сетевой безопасности.

Вот что пытаются решить все эти дебаты! У обеих сторон есть законные аргументы. Что бесполезно, так это нападки ad hominem, которые отвлекают от достойного разговора.

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

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

Никто не борется с конфиденциальностью, даже если не все борются за одно и то же.

Мы будем сообщать вам об этом по мере развития событий.

Как всегда, оставляйте комментарии или вопросы ниже…

25 комментариев

Только что услышал выступление Пола Викси на Wild West Hackin Fest в Дедвуде, Южная Дакота, в прошлую пятницу. Он подробно остановился на некоторых из этих комментариев. Видеозапись выступления должна выйти в ближайшее время.

Кажется, это опечатка. Вы имели в виду DNS через TLS?

Патрик Ноэ говорит:

Спасибо, что заметили, ошибка исправлена.

Похоже на опечатку? МЫ ВСЕ ЗНАЕМ, ЧТО ЭТО БЫЛО. Надоедливый придурок.

Виртуальные частные сети уже работают более 443 раз, поэтому кажется, что кошка уже не в курсе, блокируя DNS-трафик или просто отслеживая DNS-трафик на статистическом уровне. DoH также уже здесь — кажется, клиенты и провайдеры DNS этого хотят, это стандарт де-факто.
Если администратор сети хочет ограничить доступ ненадежных пользователей, ему придется придумать что-то, что позволит «доверенному» посреднику проверять/записывать весь трафик 443.

нам необходимо сохранить мониторинг и контроль.

ДоТ всегда!

Привет, Патрик, и спасибо за статью. Я особенно ценю утверждение "Что не помогает, так это нападки на личном опыте, которые отвлекают от достойного разговора".

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

Возвращаясь к статье. Я никогда бы не стал рассматривать аспект прав человека в споре, спасибо, что просветили меня о том факте, что на самом деле, кажется, есть законная причина для поддержки DoH вместо DoT (та, которая У меня проблемы с отставанием, поскольку DoT просто имеет больше смысла, не говоря уже о том, что он кажется почти важным с точки зрения сетевой безопасности). Определенно пища для размышлений.

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

Здравствуйте, Джон Л. Галт. Я считаю эту проблему похожей на возведение стены вокруг США. Вы можете думать, что хотите этого, пока политический режим, с которым вы не согласны, не придет к власти, а вы застрянете в нем. Только мое мнение, но то же самое с DoT. Это дало бы сетевым администраторам и администраторам безопасности некоторую власть до тех пор, пока не вмешаются черные шляпы, а под черными шляпами я имею в виду ГОСУДАРСТВО. С учетом сказанного я рассматриваю DoH как единственный выбор, но я также могу понять ваше мнение.

Я предполагаю, что при мониторинге сетевого трафика сетевые администраторы хотят в первую очередь видеть, какие адресаты за пределами их домена посещаются.
Как я понял из этой статьи, сторонники DoT утверждают, что когда кто-то использует DoT, это вызовет подозрения, что является хорошим индикатором для дальнейшего расследования. Когда тот же человек использует DoH, это подозрение не возникнет (потому что это тот же тип трафика, что и при посещении обычных веб-сайтов). Таким образом, с точки зрения безопасности (мониторинг «здорового» сетевого трафика) кажется логичным, что DoT предпочитают люди, которые хотят иметь возможность отслеживать сетевой трафик. Однако, когда все используют DoT (потому что он стал стандартом, который реализует каждая операционная система), то кажется, что вызывающий подозрение аргумент в пользу DoT становится спорным и что фактически больше не имеет значения, использует ли пользователь DoT или DOH. Я хочу подчеркнуть, что я не эксперт по сетям (безопасности), поэтому, пожалуйста, поправьте меня, если мой анализ неверен

Хорошо написано и познавательно! Спасибо.

Даже придумывать маршрутизацию базового протокола *поверх другого* базового протокола… только те же сумасшедшие люди, которые думали, что иметь платформу ОС (HTML5) *на другой* платформе ОС (вашей фактической ОС) было хорошей идеей, приходите! придумать что-нибудь *это* безумие!

В этот момент даже Xzibit посоветовал бы вам снизить цену!

Я лично обратился к лидерам WhatWG, имею опыт работы в области нейропсихологии, и настоящим свидетельствую, что этих людей нужно поместить в психиатрическую лечебницу!
Вред, который они наносят обществу в целом, находится на уровне террористической группы. Успешный.

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

Он продемонстрировал только свои корыстные интересы и эгоизм, напав на DoH за то, что он усложнил работу системным администраторам.

И, назвав всех в лагере DoH сумасшедшими лунатиками, он просто лишился всякого доверия, которое у него осталось.

Я понимаю, что DoT позволяет сетевым администраторам подтверждать трафик через порт 853, но как это полезно для управления трафиком, когда DNS-запросы (и ответы) зашифрованы? Если я что-то не упустил, вам нужно иметь возможность видеть DNS-запросы (и ответы) для управления трафиком с IP-адресов, возвращенных в ответах DNS. А так как DoT шифрует трафик, это невозможно. Например, сетевой администратор не может заблокировать или перенаправить доступ к определенным сайтам, используя информацию из трафика DoT (при условии повсеместного использования DoT), поскольку информация DNS зашифрована; они могут повсеместно блокировать DNS-трафик на порту 853, но не будет ли это почти таким же разрушительным, как блокирование всего трафика на 443, поскольку в большинстве случаев DNS необходим?

Я не сторонник и не противник DoH или DoT; Я просто хочу подтвердить, что аргументы в пользу DoT законны и добросовестны. Если предположить, что использование DoT станет повсеместным, мне кажется, что мониторинг зашифрованного трафика на порту 853 бесполезен для управления трафиком или исследования безопасности, поскольку данные не могут быть прочитаны. Я что-то пропустил?

Я действительно не вижу в этом проблемы или большого значения.

Похоже, что DoH лучше всего подходит для «интернет-трафика», поэтому власти не могут блокировать или просматривать ваш трафик…

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

По сути, когда DoH станет достаточно вездесущим, как сегодня обычный DNS, Google и Cloudflare будут вынуждены использовать системные настройки DNS по умолчанию. Большинство домашних пользователей не будут касаться этого и будут использовать серверы DoH своих интернет-провайдеров, предоставленные их маршрутизаторами DHCP. Таким образом, интернет-провайдеры снова узнают (или могут) узнать, на какие сайты заходят их пользователи, как и сегодня. И, как и сегодня, большинство правительств (даже многие из тех, которые якобы уважают «свободу») будут уговаривать интернет-провайдеров предоставить им эту информацию.

Правительства, подобные Китаю, вероятно, будут блокировать или преследовать в судебном порядке пользователей, которые не используют своих интернет-провайдеров по умолчанию или любых других «санкционированных поставщиков DoH», которые они выбрали. Таким образом, вместо текущего Tor заинтересованные пользователи должны будут иметь локальное программное обеспечение в своем браузере или компьютере, чтобы использовать обычного провайдера DoH, «санкционированного» интернет-провайдером, для «одобренного» трафика, притворяться, что они «послушны», и для конфиденциальных данных. сайты, они поразят другие серверы DoH.

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

С другой стороны, DoT явно лучше подходит для "трафика компании и VPN", чем DoH. Так что не используйте DoH внутри своей компании, используйте DoT. Я имею в виду, почему вы хотите использовать DoH в качестве системного администратора вместо DoT?

В основном для разрешения любого внутреннего IP-адреса вам необходимо использовать серверы DoT, предоставленные компанией. У вас НЕТ серверов DoH, которые вы могли бы использовать. Так что просто используйте их.

Присоединяйтесь к сообществу DZone и получите все возможности участника.

Что такое DNS?

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

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

Что такое TLS?

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

Способы связи, такие как электронная почта, сообщения и т. д., защищены протоколом TLS. TLS защищает информацию и данные веб-сайтов, обеспечивая шифрование. Основной целью TLS является обеспечение безопасности и защиты информации и данных веб-сайта. TLS защищает только те данные, которые доставляются или передаются через средства связи. Он защищает данные в конечной системе.

DNS через TLS

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

Как работает DNS через TLS?

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

DNS через версию сервера TLS начинается с инициации сеанса. DNS через TLS должен принимать TCP-соединение порта 853. При этом и использовании DoT все соединения TCP должны быть безопасными и зашифрованными. Это необходимо для защиты данных при использовании DNS через TLS.
Процесс проверки подлинности будет выполняться для подключения TLS. После подключения к DNS-клиентам процесс рукопожатия и аутентификации TLS начнется с DNS-серверов. Как только будет установлено соединение между DNS-клиентами и DNS-сервером, будет выполнено полное шифрование.

Сертификат предоставляется каждому участнику. Дополнительную информацию о сертификатах см. в разделе Управление сертификатами.

Номера в следующих таблицах относятся только к устройствам IB-FLEX. Информацию о требованиях к ЦП и памяти для устройств NIOS, отличных от IB-FLEX, см. в Примечаниях к выпуску NIOS.

Небольшой
рекурсивный DNS (с ускорением)

Только для vDCA: 120 000

Только для vADP: 50 000

Для vDCA и vADP: 120 000

Средний
рекурсивный DNS (с ускорением)

Только для vDCA: 150 000

Только для vADP: 60 000

Для vDCA и vADP: 150 000

Большой
рекурсивный DNS (с ускорением)

Только для vDCA: 240 000

Только для vADP: 80 000

Для vDCA и vADP: 240 000

В следующей таблице указано максимальное количество одновременных сеансов, поддерживаемых различными моделями устройств NIOS (физическими и виртуальными). Сведения о требованиях к ЦП и памяти см. в примечаниях к выпуску NIOS.

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

Устройство NIOS
(физическое и виртуальное)

Только для vDCA: 150 000

Только для vADP: 60 000

Для vDCA и vADP: 150 000

Только для vDCA: 240 000

Только для vADP: 80 000

Для vDCA и vADP: 240 000

Требования к конфигурации при включенном родительском контроле

Средний
рекурсивный DNS (с ускорением)

Только для vDCA: 150 000

Только для vADP: 60 000

Для vDCA и vADP: 150 000

Средний-большой
рекурсивный DNS (с ускорением)

Только для vDCA: 150 000

Только для vADP: 60 000

Для vDCA и vADP: 150 000

Большой
рекурсивный DNS (с ускорением)

Только для vDCA: 240 000

Только для vADP: 80 000

Для vDCA и vADP: 240 000

Для TLS 1.2 поддерживаются следующие наборы шифров:

Для TLS 1.3 поддерживаются следующие наборы шифров:

TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_256_GCM_SHA384

Устройства NIOS, поддерживающие ускорение кэширования DNS или программное обеспечение Advanced DNS Protection, включают функцию DNS over TLS, которая помогает повысить безопасность и конфиденциальность DNS. Когда вы включаете функцию DNS через TLS, трафик DNS шифруется с помощью протокола TLS, чтобы предотвратить прослушивание и подделку данных DNS. Эта функция поддерживается как на рекурсивных, так и на полномочных DNS-серверах только через порт 853. Она доступна только для участников Grid и для автономных систем. Он поддерживает обработку нескольких DNS-запросов/ответов в рамках одного сеанса TLS.

Вы можете настроить и запустить службу DNS через TLS на члене только при соблюдении следующих условий:

Включена либо служба ускоренного ускорения кэширования DNS (vDCA), либо служба Advanced DNS Protection Software (vADP).
Память, необходимая для поддержки функции DNS через TLS, доступна. Дополнительную информацию см. на странице 58469271 .

Настройка DNS через TLS

Чтобы настроить функцию DNS через TLS, выполните следующие действия:

Участник сетки: на вкладке "Управление данными" перейдите на вкладку "DNS" -> вкладка "Участники", установите флажок член и нажмите значок "Изменить".
Автономная система: на вкладке "Данные" Откройте вкладку "Управление", перейдите на вкладку "DNS", разверните панель инструментов и нажмите "Свойства системного DNS".
В редакторе ЧленDNSСвойства/редактор Системные свойства DNS нажмите Переключить расширенный режим, если редактор находится в базовом режиме.

На вкладке "Запросы" -> вкладка "Дополнительно" установите флажок "Включить службу DoT", чтобы включить функцию DNS через TLS.

Параметры функции DNS через TLS отображаются только в том случае, если устройство имеет объем памяти, необходимый для поддержки этой функции, и на нем установлена лицензия на программное обеспечение DNS Cache Acceleration или Advanced DNS Protection. Дополнительную информацию см. на странице 58469271 .

По запросу вручную перезагрузите участника, чтобы включить функцию DNS через TLS.

Функция DNS через TLS не вступит в силу, пока вы не перезагрузите участник или автономную систему и не убедитесь, что после перезагрузки запущена служба DNS Cache Acceleration или Advanced DNS Protection Software.

Поддержка CLI для DNS через TLS

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

Участник сетки: на вкладке "Управление данными" перейдите на вкладку "DNS" -> вкладка "Участники", установите флажок член и нажмите значок "Изменить".
Автономная система: на вкладке "Данные" Откройте вкладку "Управление", перейдите на вкладку "DNS", разверните панель инструментов и нажмите "Свойства системного DNS".
В редакторе ЧленDNSСвойства/редактор Системные свойства DNS нажмите Переключить расширенный режим, если редактор находится в базовом режиме.

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