Содержание
Настройки DNS Настройки полезной нагрузки MDM для устройств Apple
Искать в этом руководстве
Добро пожаловать
Введение в развертывание платформы Apple
Что нового
Введение в профили MDM
Введение в полезные нагрузки MDM
О контроле устройств
Выберите модель развертывания
Общие сведения о типах регистрации устройств Apple
Регистрация пользователей и MDM
Регистрация устройств и MDM
Автоматическая регистрация устройств и MDM
Развертывание Apple TV
Общий обзор iPad
Подготовьте общий iPad
Выберите решение MDM
Введение в планирование миграции MDM
Настройте новое решение MDM
Повторная регистрация устройств в MDM
Используйте сервисы, основанные на стандартах
Развертывание устройств с помощью Apple School Manager, Apple Business Manager или Apple Business Essentials
Настройка устройств
Установка приложений с помощью Apple Configurator
Добавление устройств Apple в Apple School Manager, Apple Business Manager или Apple Business Essentials
Настройте свою сеть для MDM
Подготовьтесь к использованию eSIM с устройствами Apple
Используйте MDM для развертывания устройств с сотовой связью
Настройка устройств для работы с APN
Как устройства Apple подключаются к сетям Wi-Fi
Оптимизируйте свои сети Wi-Fi
Просмотр совокупной пропускной способности для сетей Wi-Fi
Введение в кэширование контента
Настроить кэширование контента
Использовать записи DNS TXT
Расширенные настройки кэширования контента
Кэширование контента из командной строки
Метрики кэширования контента
Настройка общего интернет-соединения
Введение в службы идентификации Apple
Регистрация единого входа (SSO) для iPhone и iPad
Управляемые идентификаторы Apple
iCloud
iMessage и FaceTime
Введение в единый вход
Расширение единого входа Kerberos
Интеграция с Azure AD
Интегрируйте компьютеры Mac с Active Directory
Интеграция с Microsoft Exchange
Идентификация iPhone или iPad с помощью Microsoft Exchange
Помощник по настройке
Настройка панелей помощника по настройке в Apple TV
Настройте локальные учетные записи macOS
Планируйте свои профили конфигурации
Просмотр полезной нагрузки MDM
Обзор декларативных конфигураций
Просмотрите ограничения MDM
Об обновлениях программного обеспечения
Тестируйте и откладывайте обновления программного обеспечения
Используйте MDM для развертывания обновлений программного обеспечения
Управление элементами входа и фоновыми задачами на Mac
Введение в распространение контента
Способы распространения контента
Распространение управляемых приложений
Распространение пользовательских приложений
Распространение приложений, не включенных в список
Распространять проприетарные внутренние приложения
Распространение пользовательских пакетов для Mac
Идентификаторы пакетов для нативных приложений для iPhone и iPad
Идентификаторы пакетов для нативных приложений Apple TV
Подключайтесь к сетям 802.
1XДетали спецификации iPhone Wi-Fi
Подробная информация о спецификации Wi-Fi на iPad
Подробная информация о спецификации Wi-Fi MacBook Pro
Подробная информация о спецификации MacBook Air Wi-Fi
Подробная информация о спецификации Apple TV Wi-Fi
Обзор VPN
Поддержка Wi-Fi в роуминге
Настройка Cisco IPsec VPN
Используйте клиенты SSL VPN
Используйте VPN-прокси и конфигурацию сертификата
Фильтровать содержимое
Бонжур открытие
Используйте AirPlay
Общие сведения о безопасности управления устройствами
Блокировка и обнаружение устройств
Стереть устройства
Блокировка активации
Управление доступом к аксессуарам
Управление быстрым реагированием безопасности
Применение политик паролей
Используйте постоянные токены
Используйте встроенные функции сетевой безопасности
Аттестация управляемого устройства
Введение в управление сертификатами
Распространение сертификатов
Введение в интеграцию смарт-карт
Поддерживаемые функции смарт-карт на iPhone и iPad
Использование смарт-карты на iPhone и iPad
Поддерживаемые функции смарт-карт на Mac
Использование смарт-карты на Mac
Настройка Mac для проверки подлинности только с помощью смарт-карты
Использование FileVault и смарт-карт
Дополнительные параметры смарт-карты
Безопасность запуска
Расширения системы и ядра в macOS
Введение в FileVault
Используйте безопасные и загрузочные токены
Управление FileVault с помощью MDM
Улучшения безопасности приложений для Mac
Информация о регистрации пользователей MDM
Список полезных данных MDM для регистрации устройств
Список полезных данных MDM для автоматической регистрации устройств
Список полезной нагрузки для iPhone и iPad
Список полезной нагрузки для Mac
Список полезной нагрузки для Apple TV
Список полезной нагрузки для общего iPad
Ограничения для iPhone и iPad
Ограничения для Mac
Ограничения для Apple TV
Ограничения для контролируемых устройств
Список команд MDM
Список параметров команды настройки MDM
Запросы информации об устройстве
Запросы информации о сети устройства
Запросы операционной системы
Запросы установленных приложений
Запросы безопасности
Декларативные отчеты о состоянии
Настройки полезной нагрузки специальных возможностей
Параметры полезной нагрузки автоматизированной среды управления сертификатами (ACME)
Параметры полезной нагрузки сертификата Active Directory
Настройки полезной нагрузки AirPlay
Настройки полезной нагрузки AirPlay Security
Параметры полезной нагрузки AirPrint
Настройки полезной нагрузки App Lock
Параметры полезной нагрузки связанных доменов
Параметры полезной нагрузки автономного режима одного приложения
Настройки полезной нагрузки календаря
Настройки полезной нагрузки сотовой связи
Параметры полезной нагрузки предпочтения сертификата
Параметры полезной нагрузки отзыва сертификата
Параметры полезной нагрузки прозрачности сертификата
Параметры полезной нагрузки сертификатов
Настройки полезной нагрузки дисплея конференц-зала
Настройки полезной нагрузки контактов
Параметры полезной нагрузки кэширования контента
Параметры полезной нагрузки службы каталогов
Параметры полезной нагрузки DNS-прокси
Параметры полезной нагрузки DNS Settings
Параметры полезной нагрузки док-станции
Настройки полезной нагрузки доменов
Настройки полезной нагрузки энергосбережения
Параметры полезной нагрузки Exchange ActiveSync (EAS)
Параметры полезной нагрузки веб-служб Exchange (EWS)
Расширяемые параметры полезной нагрузки единого входа
Расширяемые параметры полезной нагрузки Kerberos для единого входа
Настройки полезной нагрузки расширений
Параметры полезной нагрузки поставщика файлов
Параметры полезной нагрузки FileVault
Настройки полезной нагрузки Finder
Параметры полезной нагрузки брандмауэра
Параметры полезной нагрузки шрифтов
Глобальные настройки полезной нагрузки HTTP-прокси
Настройки полезной нагрузки аккаунтов Google
Настройки полезной нагрузки макета главного экрана
Настройки полезной нагрузки идентификации
Параметры полезной нагрузки Identity Preference
Параметры полезной нагрузки политики расширения ядра
Параметры полезной нагрузки LDAP
Параметры полезной нагрузки Lights Out Management
Настройки полезной нагрузки сообщений экрана блокировки
Параметры полезной нагрузки управляемых элементов входа
Параметры полезной нагрузки окна входа
Настройки полезной нагрузки почты
настройки Wi-Fi
Настройки Ethernet
Настройки WEP, WPA, WPA2, WPA2/WPA3
Динамические настройки WEP, WPA Enterprise и WPA2 Enterprise
Настройки EAP
Настройки точки доступа 2.
0Устаревшие настройки точки доступа
Настройки линии быстрого доступа Cisco
Параметры конфигурации сетевого прокси
Параметры полезной нагрузки правил использования сети
Настройки полезной нагрузки уведомлений
Настройки полезной нагрузки родительского контроля
Настройки полезной нагрузки пароля
Печать параметров полезной нагрузки
Политика предпочтений конфиденциальности Управление настройками полезной нагрузки
Настройки полезной нагрузки SCEP
Параметры полезной нагрузки безопасности
Параметры полезной нагрузки помощника по настройке
Параметры полезной нагрузки единого входа
Параметры полезной нагрузки смарт-карты
Параметры полезной нагрузки календарей с подпиской
Настройки полезной нагрузки системных расширений
Параметры полезной нагрузки миграции системы
Параметры полезной нагрузки Time Machine
Настройки полезной нагрузки TV Remote
Обзор настроек VPN
Настройки полезной нагрузки AppLayerVPN
Настройки IKEv2
Параметры IPsec
Настройки L2TP
Настройки VPN-прокси
Параметры полезной нагрузки веб-клипов
Параметры полезной нагрузки Web Content Filter
Настройки полезной нагрузки Xsan
Декларативные настройки календаря
Декларативная конфигурация контактов
Декларативная конфигурация Exchange
Декларативная конфигурация учетных записей Google
Декларативная конфигурация LDAP
Декларативная конфигурация почты
Декларативная конфигурация пароля
Декларативная конфигурация календарей с подпиской
Декларативная конфигурация устаревшего профиля
Устаревшая декларативная конфигурация интерактивного профиля
Учетные данные для аутентификации и настройки актива идентификации
Присоединяйтесь к AppleSeed для ИТ
Поддержка AppleCare
Профессиональные услуги
Обучение внедрению и управлению
Сеть консультантов Apple
веб-ресурсы Apple
Глоссарий
История изменений документа
Авторские права
1X
0 Вы можете настроить параметры DNS для пользователей iPhone, iPad, общего iPad или Mac, зарегистрированных в решении для управления мобильными устройствами (MDM).
Используйте полезные данные настроек DNS, чтобы указать приложения, которые должны использовать определенные настройки DNS.
Полезная нагрузка настроек DNS поддерживает следующее. Дополнительные сведения см. в разделе Информация о полезной нагрузке.
Поддерживаемый идентификатор полезной нагрузки: com.apple.dnsSettings.managed
Поддерживаемые операционные системы и каналы: iOS, iPadOS, совместно используемое устройство iPad, устройство macOS.
Поддерживаемые типы регистрации: Регистрация устройств, автоматическая регистрация устройств.
Допускается дублирование: True — на устройство может быть доставлено более одной полезной нагрузки настроек DNS.
Вы можете использовать параметры в таблице ниже с полезными данными настроек DNS.
Setting | Description | Required | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Protocol | The encrypted transport protocol used to communicate with the DNS server. | Да | |||||||||
Имя хоста | IP-адрес или полное доменное имя (FQDN) прокси-сервера. | Нет | |||||||||
Адреса серверов | Список строк IP-адресов DNS-серверов, которые могут представлять собой сочетание адресов IPv4 и IPv6. | Нет | |||||||||
URL-адрес сервера | URL-адрес (начинающийся с https://), используемый для проверки сертификата сервера. Если это поле пусто, имя хоста или адрес в URL используются для определения адреса или адресов сервера. Требуется, если используется протокол HTTPS. | Нет | |||||||||
Соответствующие домены | Список доменов, используемый для определения того, какие DNS-запросы используют DNS-сервер. Вы также можете использовать префикс * с подстановочным знаком. Например, *.theacmeinc.com и acmeinc.com совпадают с mydomain.theacmeinc.com и your.domain.theacmeinc.com, но не совпадают с mydomain-theacmeinc.com. | № | |||||||||
Возможные варианты: HTTPS или TLS.
Если этот список отсутствует, используется DNS-сервер по умолчанию.Примечание. Каждый поставщик MDM реализует эти настройки по-разному. Чтобы узнать, как различные настройки DNS применяются к вашим устройствам, обратитесь к документации поставщика MDM.
Дата публикации: 24 октября 2022 г.
См. также Введение в профили управления мобильными устройствамиПланирование профилей конфигурации для устройств AppleВеб-сайт Apple Developer: Настройки DNS
Максимальное количество символов:
250
Пожалуйста, не указывайте личную информацию в своем комментарии.
Максимальное количество символов — 250.
Спасибо за отзыв.
Повышение безопасности DNS для приложений и серверов — WWDC22 — Видео
Больше видео
Откройте для себя новейшие способы обеспечения безопасности DNS — основы интернет-адресации — в вашем приложении. Узнайте, как аутентифицировать ответы DNS в вашем приложении с помощью DNSSEC и автоматически включать шифрование DNS с помощью Discovery of Designated Resolvers (DDR).
Ресурсы
Похожие видео
WWDC 2020
Скачать
Цяоюй Дэн: Привет. Добро пожаловать в раздел «Повышение безопасности DNS для приложений и серверов». Меня зовут Цяою Дэн. В этом видео мы поговорим о том, почему DNS часто бывает небезопасным и как защитить его с помощью DNSSEC и зашифрованного DNS с DDR. Во-первых, давайте поговорим о том, почему DNS небезопасен.
DNS — это телефонная книга Интернета.
Он переводит доменные имена, понятные для человека и легко запоминающиеся, в IP-адреса, созданные для машин. Другие интернет-протоколы, такие как TCP, TLS и QUIC, полагаются на наличие IP-адреса, поэтому все начинается с DNS. Сегодня TLS широко используется для защиты интернет-коммуникаций. Это здорово, но DNS, базовый уровень, имеет некоторые проблемы с безопасностью. DNS исторически небезопасен. Он был разработан еще в 1983 году с некоторыми соображениями безопасности. С тех пор было создано множество DNS-атак. Одним из примеров является отравление кеша DNS, когда злоумышленник использует недостатки распознавателей DNS и заставляет их кэшировать неправильные IP-адреса, заставляя клиентов подключаться к вредоносным хостам. Это выявляет одну уязвимость DNS: она не аутентифицируется. Традиционные DNS-клиенты сегодня не имеют возможности проверять ответы, поэтому их легко подделать. Другой распространенной атакой является прослушивание DNS, когда злоумышленник просматривает DNS-трафик между клиентом и DNS-сервером, собирая историю клиента. Это серьезная проблема для конфиденциальности пользователей. Причина, по которой эта атака возможна, заключается в том, что трафик DNS изначально не был зашифрован. Чтобы быть безопасной отправной точкой для протоколов, которые строятся поверх него, DNS должен быть как аутентифицированным, так и зашифрованным. Когда мы используем DNSSEC для подписи ответа DNS, он обеспечивает аутентификацию. Когда мы используем TLS и HTTPS для шифрования разрешения DNS, это обеспечивает конфиденциальность. Далее поговорим о DNSSEC. DNSSEC — это набор спецификаций расширений, созданный IETF. Многие поставщики услуг DNS уже поддерживают его, но клиентская поддержка все еще расширяется. iOS 16 и macOS Ventura теперь поддерживают проверку DNSSEC на стороне клиента. DNSSEC обеспечивает аутентификацию данных путем добавления цифровых подписей. Он защищает целостность данных. Он аутентифицирует отрицание существования, когда ответов не существует. Он также обеспечивает криптографическую аутентификацию. DNSSEC защищает целостность данных, присоединяя к ответам подписи. Если ответ изменен злоумышленником, подпись измененных данных не будет соответствовать исходной. В этом случае клиент может обнаружить измененный ответ и отбросить его. DNSSEC также подтверждает существование и отсутствие записей в зоне с помощью специальных типов записей DNS, таких как запись NSEC. Запись NSEC сообщает вам имя следующей записи в алфавитном порядке. Имена, перечисленные в нем, — это те, которые существуют, и любое имя, не указанное в нем, не существует. Например, у нас есть три записи NSEC. Набор записей показывает, что зона org имеет только три имени записи: A.org, C.org и E.org. Теперь, если есть злоумышленник, который говорит, что A.org не существует, клиент может обнаружить эту атаку. A.org существует, потому что он указан в первой записи NSEC. Точно так же, если злоумышленник говорит, что D.org существует, клиент также может обнаружить это, потому что, согласно второй записи NSEC, D.org находится между C.org и E.org, и между двумя именами не должно быть имени. . DNSSEC аутентифицирует записи, устанавливая цепочку доверия. Вот пример. Устройство хочет разрешить www.example.org с включенной проверкой DNSSEC. Он отправляет запросы, запрашивающие IP-адреса, подписи и ключи. С помощью ответов можно построить доверительные отношения от IP-адресов до ключа номер 1. Затем клиент отправляет запросы в родительскую зону, org, запрашивая записи, которые можно использовать для аутентификации ключа номер 1, чтобы он мог построить доверительные отношения от ключа номер 1 до ключа номер 2. Таким образом, устройство рекурсивно повторяет этот процесс, пока не достигнет корня. Теперь, если можно доверять корневому ключу, который на диаграмме является ключом номер 3, можно аутентифицировать доверительные отношения от IP-адресов до ключа номер 3. Хэш корневого ключа всегда надежно хранится на устройстве. В DNSSEC это называется якорем корневого доверия. Если хэш ключа номер 3 совпадает с предустановленным якорем, цепочка доверия может быть надежно установлена. Благодаря цепочке доверия IP-адреса www.example.org теперь аутентифицируются.Если вы хотите требовать проверки DNSSEC в своих приложениях, вот что вам нужно сделать. Поддержка IPv6 для ваших доменов. В среде только для IPv6 адреса только для IPv4 преобразуются в синтетические адреса IPv6. Если домены подписаны, синтезированные адреса не могут пройти проверку DNSSEC; они недоступны при включенном DNSSEC. Поэтому убедитесь, что ваши домены поддерживают IPv6. Убедитесь, что ваш поставщик услуг DNS подписывает ваш домен с помощью DNSSEC. Если вы включите DNSSEC в своем приложении без подписи своего домена, вы не получите никаких преимуществ, но вы получите дополнительный DNS-трафик и увеличенное время разрешения попытки аутентификации для вашего неподписанного домена. Если у вас есть соответствующая поддержка инфраструктуры, вот код, необходимый для внедрения DNSSEC для ваших приложений. Если вы являетесь клиентом NSURLSession, вы можете потребовать проверки DNSSEC для своего запроса URL. Вот пример. Сначала вы создадите конфигурацию сеанса по умолчанию. Затем вам потребуется проверка DNSSEC.
Далее вы создадите сеанс с измененной конфигурацией. Он включает DNSSEC для всех запросов URL, созданных в этом сеансе. Если вы не хотите включать DNSSEC для всего сеанса, вы также можете сделать это на уровне запроса. Сначала создайте сеанс с конфигурацией по умолчанию, в которой проверка DNSSEC отключена. Затем включите его в запросе. Теперь эта задача сеанса будет запущена только после завершения проверки DNSSEC. Если вы являетесь клиентом Network.framework, вы также можете потребовать проверки DNSSEC для своих подключений. Во-первых, при создании объекта параметров требуется проверка DNSSEC. Затем создайте NWConnection с объектом параметров. Теперь, когда вы начнете подключение, оно перейдет в состояние готовности только после завершения проверки DNSSEC и установления подключения к проверенному IP-адресу. Когда DNSSEC включен, для установления соединения будут использоваться только проверенные адреса. В HTTPS об ошибках сообщается через API. В DNSSEC ошибка проверки не возвращается. Получение ответа, не прошедшего проверку, равнозначно неполучению ответа. Если есть провайдер DNS, который подделывает ответ, адреса не пройдут проверку аутентификации, поэтому они будут отброшены напрямую. Когда устройство подключается к новой сети, в которой провайдер DNS не вмешивается в ответы, проверка снова продолжится, и разрешение автоматически вернется к нормальному состоянию.Вот несколько случаев, которые могут привести к сбою DNSSEC. Когда исходный ответ DNS изменен, несоответствующая подпись не пройдет проверку DNSSEC, что приведет к сбою проверки. Когда устройство не может подключиться ни к одному предварительно установленному якорю доверия и не может установить из него цепочку доверия. Когда сеть не поддерживает необходимые протоколы, требуемые DNSSEC, такие как DNS через TCP и параметр EDNS0, который содержит бит включения DNSSEC. Если подписанный домен не поддерживает IPv6, синтезированные адреса IPv6, предоставленные интернет-провайдером, не пройдут проверку.
Так вот как аутентифицировать ответы DNS с помощью DNSSEC, но если они все еще не зашифрованы, любой в сети может их увидеть. Далее мы поговорим о том, как включить шифрование DNS автоматически с помощью DDR.В iOS 14 и macOS Big Sur мы представили зашифрованный DNS для сохранения конфиденциальности. Вы можете использовать NEDNSSettingsManager в приложении или DNSSettings в профиле, чтобы вручную настроить шифрование DNS для всей системы. Вы также можете выбрать зашифрованный DNS для своего приложения, используя PrivacyContext в NWParameters. Дополнительные сведения см. в разделе «Включить зашифрованный DNS». Новое в iOS 16 и macOS Ventura: зашифрованный DNS можно использовать автоматически. Если ваша сеть поддерживает обнаружение назначенных преобразователей, также называемое DDR, DNS-запросы будут автоматически использовать TLS или HTTPS. Чтобы использовать зашифрованный DNS, ваше устройство должно знать, что резолвер поддерживает TLS или HTTPS, а также может потребоваться узнать порт или URL-адрес.
Обычные механизмы, такие как DHCP или объявления маршрутизатора, предоставляют только простой IP-адрес. DDR — это новый протокол, разработанный Apple в рамках IETF совместно с другими отраслевыми партнерами. Он предоставляет DNS-клиентам возможность узнать необходимую информацию с помощью специального DNS-запроса. Когда ваше устройство подключается к новой сети, оно выдает запрос привязки службы для «_dns.resolver.arpa». Если DNS-сервер поддерживает DDR, он ответит одной или несколькими конфигурациями. Затем устройство использует эту информацию для установки зашифрованного соединения с назначенным преобразователем. Он проверяет, включен ли IP-адрес незашифрованного преобразователя в сертификат TLS назначенного преобразователя. Это делается для того, чтобы незашифрованный преобразователь и зашифрованный принадлежали одному и тому же объекту. Если все выглядит хорошо, устройство теперь использует зашифрованный DNS по умолчанию.DDR одновременно применяется к одной сети. Ваше устройство будет использовать зашифрованный DNS автоматически, только если текущая сеть поддерживает это.
Также важно отметить, что DDR не работает, если IP-адрес вашего DNS-сервера является частным IP-адресом. Это связано с тем, что такие IP-адреса не разрешены в сертификатах TLS, поскольку их право собственности не может быть подтверждено. В iOS 16 и macOS Ventura мы также поддерживаем возможность указать проверку подлинности клиента при использовании зашифрованного DNS для настройки конфигурации, используя NEDSSettingsManager или профиль DNSSettings.Проверка подлинности клиента позволяет использовать зашифрованные DNS-серверы в корпоративных средах, где серверам необходимо проверять клиентов перед предоставлением доступа. Теперь вы можете настроить сертификат клиента, используя свойство identityReference в NEDSSettings. Это ведет себя так же, как клиентские сертификаты для VPN. Они могут применяться как к DNS через TLS, так и к DNS через HTTPS. Это путь к защите DNS. Подпишите свой домен с помощью DNSSEC и требуйте проверки DNSSEC в своих приложениях для аутентификации ваших IP-адресов.
Он переводит доменные имена, понятные для человека и легко запоминающиеся, в IP-адреса, созданные для машин. Другие интернет-протоколы, такие как TCP, TLS и QUIC, полагаются на наличие IP-адреса, поэтому все начинается с DNS. Сегодня TLS широко используется для защиты интернет-коммуникаций. Это здорово, но DNS, базовый уровень, имеет некоторые проблемы с безопасностью. DNS исторически небезопасен. Он был разработан еще в 1983 году с некоторыми соображениями безопасности. С тех пор было создано множество DNS-атак. Одним из примеров является отравление кеша DNS, когда злоумышленник использует недостатки распознавателей DNS и заставляет их кэшировать неправильные IP-адреса, заставляя клиентов подключаться к вредоносным хостам. Это выявляет одну уязвимость DNS: она не аутентифицируется. Традиционные DNS-клиенты сегодня не имеют возможности проверять ответы, поэтому их легко подделать. Другой распространенной атакой является прослушивание DNS, когда злоумышленник просматривает DNS-трафик между клиентом и DNS-сервером, собирая историю клиента.
Это серьезная проблема для конфиденциальности пользователей. Причина, по которой эта атака возможна, заключается в том, что трафик DNS изначально не был зашифрован. Чтобы быть безопасной отправной точкой для протоколов, которые строятся поверх него, DNS должен быть как аутентифицированным, так и зашифрованным. Когда мы используем DNSSEC для подписи ответа DNS, он обеспечивает аутентификацию. Когда мы используем TLS и HTTPS для шифрования разрешения DNS, это обеспечивает конфиденциальность. Далее поговорим о DNSSEC. DNSSEC — это набор спецификаций расширений, созданный IETF. Многие поставщики услуг DNS уже поддерживают его, но клиентская поддержка все еще расширяется. iOS 16 и macOS Ventura теперь поддерживают проверку DNSSEC на стороне клиента. DNSSEC обеспечивает аутентификацию данных путем добавления цифровых подписей. Он защищает целостность данных. Он аутентифицирует отрицание существования, когда ответов не существует. Он также обеспечивает криптографическую аутентификацию. DNSSEC защищает целостность данных, присоединяя к ответам подписи.
Если ответ изменен злоумышленником, подпись измененных данных не будет соответствовать исходной. В этом случае клиент может обнаружить измененный ответ и отбросить его. DNSSEC также подтверждает существование и отсутствие записей в зоне с помощью специальных типов записей DNS, таких как запись NSEC. Запись NSEC сообщает вам имя следующей записи в алфавитном порядке. Имена, перечисленные в нем, — это те, которые существуют, и любое имя, не указанное в нем, не существует. Например, у нас есть три записи NSEC. Набор записей показывает, что зона org имеет только три имени записи: A.org, C.org и E.org. Теперь, если есть злоумышленник, который говорит, что A.org не существует, клиент может обнаружить эту атаку. A.org существует, потому что он указан в первой записи NSEC. Точно так же, если злоумышленник говорит, что D.org существует, клиент также может обнаружить это, потому что, согласно второй записи NSEC, D.org находится между C.org и E.org, и между двумя именами не должно быть имени. . DNSSEC аутентифицирует записи, устанавливая цепочку доверия.
Вот пример. Устройство хочет разрешить www.example.org с включенной проверкой DNSSEC. Он отправляет запросы, запрашивающие IP-адреса, подписи и ключи. С помощью ответов можно построить доверительные отношения от IP-адресов до ключа номер 1. Затем клиент отправляет запросы в родительскую зону, org, запрашивая записи, которые можно использовать для аутентификации ключа номер 1, чтобы он мог построить доверительные отношения от ключа номер 1 до ключа номер 2. Таким образом, устройство рекурсивно повторяет этот процесс, пока не достигнет корня. Теперь, если можно доверять корневому ключу, который на диаграмме является ключом номер 3, можно аутентифицировать доверительные отношения от IP-адресов до ключа номер 3. Хэш корневого ключа всегда надежно хранится на устройстве. В DNSSEC это называется якорем корневого доверия. Если хэш ключа номер 3 совпадает с предустановленным якорем, цепочка доверия может быть надежно установлена. Благодаря цепочке доверия IP-адреса www.example.org теперь аутентифицируются.
Далее вы создадите сеанс с измененной конфигурацией. Он включает DNSSEC для всех запросов URL, созданных в этом сеансе. Если вы не хотите включать DNSSEC для всего сеанса, вы также можете сделать это на уровне запроса. Сначала создайте сеанс с конфигурацией по умолчанию, в которой проверка DNSSEC отключена. Затем включите его в запросе. Теперь эта задача сеанса будет запущена только после завершения проверки DNSSEC. Если вы являетесь клиентом Network.framework, вы также можете потребовать проверки DNSSEC для своих подключений. Во-первых, при создании объекта параметров требуется проверка DNSSEC. Затем создайте NWConnection с объектом параметров. Теперь, когда вы начнете подключение, оно перейдет в состояние готовности только после завершения проверки DNSSEC и установления подключения к проверенному IP-адресу. Когда DNSSEC включен, для установления соединения будут использоваться только проверенные адреса. В HTTPS об ошибках сообщается через API. В DNSSEC ошибка проверки не возвращается.
Получение ответа, не прошедшего проверку, равнозначно неполучению ответа. Если есть провайдер DNS, который подделывает ответ, адреса не пройдут проверку аутентификации, поэтому они будут отброшены напрямую. Когда устройство подключается к новой сети, в которой провайдер DNS не вмешивается в ответы, проверка снова продолжится, и разрешение автоматически вернется к нормальному состоянию.
Так вот как аутентифицировать ответы DNS с помощью DNSSEC, но если они все еще не зашифрованы, любой в сети может их увидеть. Далее мы поговорим о том, как включить шифрование DNS автоматически с помощью DDR.
Обычные механизмы, такие как DHCP или объявления маршрутизатора, предоставляют только простой IP-адрес. DDR — это новый протокол, разработанный Apple в рамках IETF совместно с другими отраслевыми партнерами. Он предоставляет DNS-клиентам возможность узнать необходимую информацию с помощью специального DNS-запроса. Когда ваше устройство подключается к новой сети, оно выдает запрос привязки службы для «_dns.resolver.arpa». Если DNS-сервер поддерживает DDR, он ответит одной или несколькими конфигурациями. Затем устройство использует эту информацию для установки зашифрованного соединения с назначенным преобразователем. Он проверяет, включен ли IP-адрес незашифрованного преобразователя в сертификат TLS назначенного преобразователя. Это делается для того, чтобы незашифрованный преобразователь и зашифрованный принадлежали одному и тому же объекту. Если все выглядит хорошо, устройство теперь использует зашифрованный DNS по умолчанию.
Также важно отметить, что DDR не работает, если IP-адрес вашего DNS-сервера является частным IP-адресом. Это связано с тем, что такие IP-адреса не разрешены в сертификатах TLS, поскольку их право собственности не может быть подтверждено. В iOS 16 и macOS Ventura мы также поддерживаем возможность указать проверку подлинности клиента при использовании зашифрованного DNS для настройки конфигурации, используя NEDSSettingsManager или профиль DNSSettings.