dxdt.blog: занимательный интернет-журнал

Нередко спрашивают, что такое DNSCrypt и зачем это нужно. Некоторое время назад я уже писал про DNSCrypt, применительно к “Яндекс.Браузеру”, тогда речь шла о поддержке в бета-версии браузера. В этот раз посмотрим на технологию в подробностях, а “Яндекс.Браузер” послужит примером и источником лабораторных данных. Разбор пакетов я провожу в Wireshark, для которого написал небольшой парсер DNSCrypt (в терминологии Wireshark – это dissector, на языке Lua; штатного парсера DNSCrypt в Wireshark-е мне выявить не удалось).

DNSCrypt – это прокси-сервис, создающий защищённый канал между клиентским резолвером DNS и рекурсивным DNS-резолвером, исполняемым на сервере. У DNSCrypt, соответственно, две части: клиентская и серверная. Через трафик DNS, который штатно передаётся в открытом виде, могут утекать сведения о посещаемых сайтах. Кроме того, запросы DNS – распространённый вектор атак для подмены адресов. Замена адреса системного резолвера DNS на адрес подставного сервера является общим местом троянских программ уже много лет. То же самое относится к атакам на домашние роутеры. DNSCrypt позволяет зашифровать (а также – ограниченно защитить от подмены) и запросы, и ответы DNS. Предусмотрена возможность аутентификации сервера и клиента, но эта возможность не всегда используется. Вообще, тема сокрытия DNS-трафика (DNS Privacy) сейчас набрала заметную популярность. Кроме DNSCrypt, существует, например, протокол “DNS через TLS” (DNS over TLS – свежий RFC 7858, который, несмотря на некоторую “перевёрнутость”, выглядит не хуже DNSCrypt). Есть и другие разработки.

DNSCrypt. Протокол может использовать в качестве транспорта как TCP, так и UDP. На практике, предпочтение отдаётся UDP, если он доступен, но спецификация строго требует поддержки именно TCP (не UPD, поддержка которого опциональна). TCP, естественно, привлекает сессионной природой. Но UDP – гораздо быстрее, особенно для нагруженных сервисов. Из-за проблем с DDoS-атаками и некоторых других вопросов обеспечения безопасности, сейчас наметилось модное движение в сторону перевода максимального числа сервисов на TCP, это особенно касается DNS. Тем не менее, ниже я рассматриваю работу DNSCrypt только по UDP, так как это традиционный для DNS вариант. Рекомендованный номер (серверного) порта DNSCrypt – 443 (он обычно открыт в корпоративных сетях; практика использования 443/udp, например, является стандартной для целого ряда VPN и других сервисов; 443/tcp – это TLS/HTTPS, фундамент веб-сервисов). Впрочем, “Яндекс” в своей реализации DNSCrypt использует непривилегированный номер: 15353, вероятно, это связано с какими-то идеями по преодолению разнообразных сетевых барьеров.

Чуть подробнее о барьерах: никаких проблем с блокированием трафика DNSCrypt, при наличии такого желания у провайдера канала, не возникнет. Как будет ясно из описания ниже, этот протокол никак не пытается скрыть сам факт своего использования. В трафик данного протокола включаются стандартные маркеры, которые позволят обнаружить и зафильтровать пакеты даже на самом примитивном маршрутизаторе, с помощью нехитрого правила “в две строчки”. При этом, например, доступ для других TCP-сессий, работающих на 443 порту, сохранится.

В DNSCrypt установление сессии между клиентом и сервером начинается с обычного DNS-запроса, отправленного на адрес и соответствующий номер порта узла, который будет предоставлять функции резрешения (резолвинга) имён. Это запрос TXT-записи для имени специального вида (то есть, запрос уже можно легко зафильтровать). Например, в случае с сервисом “Яндекса”: 2.dnscrypt-cert.browser.yandex.net. Это специальное имя может быть не делегировано. Значение 2 – соответствует версии DNSCrypt. Актуальная версия – вторая. В ответ сервер должен прислать один или несколько сертификатов DNSCrypt (подчеркну: они не имеют никакого отношения к SSL-сертификатам).

На скриншоте – пакет с сертификатом от сервера DNSCrypt “Яндекса”.

Сертификат представляет собой набор из нескольких полей: версия сертификата, значение подписи, открытый ключ сервера, magic-байты для клиента (они послужат идентификатором клиентских запросов – сервер сможет понять, какой ключ использовать при ответе), серийный номер и срок действия.

Спецификация предполагает, что в составе сертификата сервер передаёт кратковременный открытый ключ. (Впрочем, в случае с сервером “Яндекса”, данный ключ не меняется, как минимум, с конца марта, когда была запущена бета-версия браузера с поддержкой DNSCrypt.) Подпись на сертификате должна генерироваться от другой пары ключей. Открытый ключ этой пары известен клиенту – он необходим для проверки подписи. Очевидно, подписывать сертификат тем же ключом, который используется в рамках сессии – бессмысленно. Я не проверял, проводит ли валидацию серверного сертификата “Яндекс.Браузер”. Дело в том, что в модели угроз, на которую ориентировано использование DNSCrypt в “Яндекс.Браузере”, валидация сертификата особого смысла не имеет, как и сравнение значения ключа с сохранённой копией (я вернусь к этому моменту ниже).

В качестве криптографических примитивов DNSCrypt использует конструкции из шифра Salsa20 (XSalsa20), хеш-функции Poly1305 (для реализации аутентифицированного шифрования) и алгоритм X25119-hsalsa20 для выработки общего сеансового ключа (алгоритм использует эллиптическую кривую Curve25119 и хеш-функцию hsalsa20). Эти конструкции разработаны Даниэлем Бернштейном (Daniel J. Bernstein) и давно получили признание как весьма добротные. Алгоритм получения общего секрета (сеансового ключа) математически родственен алгоритму Диффи-Хеллмана. Отмечу, что общий секрет в данном случае можно восстановить постфактум, если станет известен соответствующий секретный ключ из пары серверных (или клиентских) ключей, это позволит расшифровать ранее записанный трафик, именно поэтому спецификация рекомендует использовать кратковременные ключи.

Шифр XSalsa20 в режиме аутентифицированного шифрования требует nonce длиной 192 бита (24 байта). Повторное использование одного и того же сочетания ключа и nonce не допускается. Это связано с архитектурой шифра XSalsa20 – повторное использование nonce приведёт к утечке: прослушивающей стороне станет известно значение XOR от пары соответствующих открытых текстов. Поэтому nonce должно быть каждый раз новым, но не обязательно случайным. Параметр nonce в DNSCrypt присутствует в двух воплощениях: клиентской и серверной.

Посмотрим на зашифрованный клиентский запрос, отправляемый “Яндекс.Браузером”.

Первое поле запроса – это клиентское значение magic (Client query magic bytes): здесь используется часть открытого ключа сервера, полученная ранее. При необходимости, данные “магические байты” могут служить сигнатурой, позволяющей выбирать в трафике запросы, отправляемые к DNSCrypt;
Следующее поле – кратковременный клиентский открытый ключ (Client public key);
Клиентское значение nonce – 96 бит (12 байтов), половина от требуемого значения nonce для шифра XSalsa20 (согласно спецификации DNSCrypt, дополняется байтами со значением 0). Можно использовать тот или иной счётчик, “Яндекс.Браузер” так и поступает: cудя по всему, здесь передаётся 64-битное значение миллисекундного таймстемпа (время формирования запроса), к которому дописываются четыре байта псевдослучайных значений. На случай, если это действительно точное время, передаваемое в открытом виде, отмечу, что параметры дрейфа системных часов служат неплохим признаком, идентифицирующим конкретное аппаратное устройство, – то есть, могут быть использованы для деанонимизации;
Последнее поле – это сам зашифрованный запрос. Для шифрования используется общий секретный ключ, который вычисляется сторонами на основании переданных открытых ключей. В случае с клиентом – открытый ключ передаётся в пакете DNS-запроса (см. выше). “Яндекс.Браузер” следует стандартной практике и генерирует новую пару ключей (открытый/секретный) для X25119-hsalsa20 при каждом старте барузера. Для выравнивания данных на границу 64-байтового блока, как предписывает спецификация, используется стандартное дополнение (ISO/IEC 7816-4: 0x80 и нулевые байты в требуемом количестве).

Блок зашифрованных данных – это, скорее всего, результат использования функции crypto_box из библиотеки libsodium (либо NaCl, на которую ссылается спецификация DNSCrypt; libsodium – это форк NaCl). Я предположил, что 16-байтовый код аутентификации (MAC), который используется для проверки целостности сообщения перед расшифрованием, находится, вероятно, в начале блока. Впрочем, так как расшифровать данные я не пытался, то и определение расположения кода не столь важно. Для расшифрования можно использовать секретный ключ, который содержится в памяти во время работы браузера, но чтобы его извлечь – нужно некоторое время повозиться с отладчиком и дизассемблером.

Зашифрованный ответ, полученный от сервера:

(Нетрудно заметить, что ответ, представленный на скриншоте, поступил почти через пять секунд после запроса, почему так получилось – видимо, тема для отдельной записки.)

Пакет открывается magic, в данном случае, это байты, содержащие маркер ответа DNSCrypt (опять же, хорошая сигнатура для обнаружения трафика). Эти байты определены протоколом и должны присутствовать в начале всякого ответа сервера на запрос DNS-резолвинга;
Следующее поле – nonce (Response nonce). Поле содержит значение nonce, использованное сервером при шифровании данного ответа. Поле строится из двух равных частей, по 12 байтов: nonce из соответствующего клиентского запроса и серверное дополнение;
Заключительная часть пакета – зашифрованные данные ответа, формат аналогичен запросу.

Теперь вернёмся к модели угроз, на примере “Яндекс.Браузера”. Если в настройках браузера включено использование DNSCrypt, например, через серверы “Яндекса”, но доступ к соответствующему серверу заблокирован, то браузер (как и бета-версия) прозрачно, без предупреждений, переходит к использованию системного резолвера. Почему это лишает смысла необходимость валидации сертификатов серверов DNSCrypt? Потому что активная атакующая сторона, которая может подменять пакеты на уровне IP, для отключения DNSCrypt в браузере может просто заблокировать доступ к серверу, вместо того, чтобы тратить ресурсы на поделку ответов. Из этого можно сделать вывод, что модель угроз “Яндекса” не включает активную подмену пакетов на пути от сервера DNSCrypt к клиенту.

В качестве завершения, пара слов о том, как DNSCrypt относится к DNSSEC. DNSSEC – не скрывает данные DNS-трафика, но защищает их от подмены, вне зависимости от канала обмена информацией. В случае с DNSSEC – не имеет значения, по какому каналу получены данные из DNS, главное, чтобы ключи были на месте. DNSCrypt – скрывает трафик и ограниченно защищает его от подмены на пути от рекурсивного резолвера (сервиса резолвинга) до клиента. Если данные были подменены на пути к резолверу (или на самом сервере резолвера), а он не поддерживает DNSSEC, то клиент получит искажённую информацию, хоть и по защищённому DNSCrypt каналу. Серверы, предоставляющие DNSCrypt, могут поддерживать и DNSSEC.

ICANN опубликовала документ (PDF), описывающий план по замене действующего корневого ключа KSK глобальной DNS на новый (ротацию KSK). Корневой KSK – это ключ, удостоверяющий данные в корневой зоне (он используется не напрямую, а через ZSK – ключ подписи зоны, но это детали). DNSSEC запустили в корне DNS в 2010 году без утверждения процедуры ротации главного ключа. Сейчас такая процедура появилась.

В кратком изложении план выглядит так: в апреле этого, 2016, года запустят процесс генерации нового KSK; в январе следующего (2017) года этот новый KSK должен быть опубликован в корневой зоне, при публикации он будет подписан действующим KSK; в апреле 2017 года новый KSK заменит старый при подписи ZSK, а спустя несколько месяцев – старый KSK будет отозван и, следующим шагом, удалён из DNS. Кроме того, в январе 2017 новый KSK должен быть опубликован другими способами, не в DNS.

Заменить корневой KSK необходимо во всех валидирующих резолверах. Те из них, которые поддерживают автоматизированный процесс (RFC 5011), смогу установить ключ автоматически (проверив данные из DNS). В других случаях – нужно заменить ключ вручную.

Сейчас для корневого KSK используется RSA-2048. Замены алгоритма или длины ключа при первой ротации не запланировано (одна из основных претензий к DNSSEC – криптосистема RSA и малая длина ключа).

Так как появились странные (невнятно сформулированные) слухи о недоступности DNS от Google из Рунета, я померил доступность при помощи сервиса RIPE Atlas – доступ есть, вот результат, на карте:

Измерение я проводил для 8.8.8.8, через 252 RIPE-зонда (probes), расположенных в Москве и ближайших регионах, в качестве запроса использовалось имя iana.org. Полученный адрес (верный) указан в легенде на картинке.

В среду с доменом MIL (это зона для военных структур США) приключилась глобальная проблема: сломалась цепочка DNSSEC, так как опубликованная в корневой зоне DS-запись не соответствовала ключу KSK, опубликованному в зоне MIL. Это означает, что валидирующий резолвер должен выдавать ошибку валидации – и ресурсы, размещённые в зоне, для клиентов такого резолвера оказываются недоступны. Как минимум, нарушилась цепочка, ведущая к глобальному ключу IANA. Интересно, что мало кто проблему вообще заметил, а чинили более 12 часов (связано с кешированием и регламентом обновления зон). Возможно, конечно, что внутри пентагоновских сетей используется другой корневой ключ и другой набор DNS-записей для валидирования – соответственно, их резолверы продолжали работать. На мой взгляд, более вероятно, что DNSSEC там на рекурсивных резолверах просто не используют, как и практически во всём остальном мире.

(Причиной “расклеивания” цепочки могли явиться изменения в настройках серверов имён, либо замена самих серверов, в результате, наружу вылез “не тот ключ”, DS-запись при этом осталась старой. Но это просто догадки.)

Когда в 2010 году технологию DNSSEC внедрили в корневой зоне DNS – не подумали об алгоритме ротации (замены) корневого ключа. В процессе генерирования безопасного файла зоны участвуют два ключа: KSK и ZSK – последний подписывает записи в зоне, а первый, KSK, это и есть корневой ключ, он удостоверяет ZSK. Соответственно, вся валидация делается от корневого KSK (в зонах, которые находятся уровнем ниже, тоже есть свои KSK, но глобальный, корневой, порождает всю цепочку). Всякий валидирующий DNS-резолвер, если он работает с глобальной DNSSEC от IANA, должен содержать копию открытого ключа корневого KSK, это необходимо для проверки подписей из безопасных зон. В общем, корневой KSK – самый важный элемент инфраструктуры DNSSEC, и технология была запущена без алгоритма регулярной замены этого ключа (хотя про интервал замены “раз в пять лет” речь шла). Бывает.

Сейчас истекли пять лет с момента публикации подписанной корневой зоны DNS. KSK пора бы обновить. Это ключ RSA, имеющий длину 2048 бит. Маловероятно, что кто-то успел его факторизовать за пять лет, но есть же и криптографические традиции. Поэтому ICANN ведёт разработку алгоритма ротации корневого KSK, сейчас предварительный документ с рекомендациями проходит стадию публичного обсуждения.

Рекомендовано сохранить используемую криптосистему (RSA) и разрядность ключа (2048 бит), а дата ротации пока никакими рекомендациями не обозначена. Учитывая, что сейчас идёт процесс по “передачи IANA-функции”, всякие решения по точным алгоритмам и датам – могут только затягиваться (в документе по ссылке про изменение политик IANA, конечно, упомянуто).

Вообще, DNSSEC не слишком широко поддерживается – подписанных зон чрезвычайно мало. Не велико и число операторов валидирующих резолверов. Среди них, наверное, самый влиятельный по объёму запросов – Google, который предоставляет сервис Public DNS, поддерживающий DNSSEC. В теории, впрочем, при неудачной замене корневого KSK все валидирующие резолверы через некоторое время сломаются, потому что любая безопасная зона подписана от корня DNS, а подписи в корне перестанут валидироваться. На практике, новый KSK, с проверкой, можно раздать по крупным операторам вручную, а мелкие – починятся после того, как обнаружат сбой. (Несмотря на то, что есть RFC 5011, надеяться на массовую успешную автоматическую замену ключа было бы очень наивно – это уже не в традициях системного администрирования.)

Интересно, что если замена ключа наложится на замену договора с IANA, то процесс затянется ещё на несколько лет. Вообще, в рекомендациях упомянут 2030 год, как год, до которого можно смело использовать 2048-битные ключи RSA, полагая их стойкими (естественно, с оговоркой про “прорывные достижения”). То есть, время для ротации KSK, похоже, ещё есть.

US-CERT распространил новое предупреждение об угрозе: “трансфер зоны DNS может раскрыть информацию о домене“. Это довольно странно, потому что известно очень много лет, соответственно – какая новая угроза? (В предупреждении, впрочем, сказано, что причина в большом распространении серверов, разрешающих трансфер зроны для всех желающих.)

Запросы AXFR (Asynchronous Transfer Full Range) – трансфер зоны – позволяют получить с сервера имён полный список записей в зоне DNS, то есть, фактически, увидеть все настройки адресации домена. Эти запросы используются для передачи сведений между разными авторитативными серверами, поддерживающими зону, а также в других случаях. Разумное толкование подсказывает, что все данные, публикуемые в глобальной DNS, должны являться публичными, по определению. Те не менее, доступ на трансфер зоны обычно ограничивают некоторыми доверенными серверами, чтобы не всякий мог скачать всю зону одним запросом, а только те узлы, которым это нужно. Так делается много лет.

Вообще, споры о том, нужно ли считать угрозой возможность получения полного (или близкого к полному) списка записей в той или иной доменной зоне – идут уже сильно дольше десяти лет. Например, этот момент повлиял на технологию DNSSEC. Для того, чтобы подтвердить, что записи для некоторого имени не существует, в DNSSEC нужно передавать в ответ на запрос указание на “ближайшую” существующую запись (на имя записи). Изначально разработчики DNSSEC пошли по “открытому пути” и предложили решение с записями NSEC, которые, в ответ на запрос о несуществующем имени, просто включают одно из имён в зоне, в открытом виде. Естественно, это позволяет быстро перебрать все записи и получить полный список имён, реконструировав зону. Защитники “безопасности через сокрытие” выставили кучу возражений, в результате появилось расширение NSEC3, где ответы содержат не сами имена, а значения хеш-функций, что делает перебор вычислительно трудным.

Так вот теперь, похоже, нужно ждать свежего “открытия” “угрозы” раскрытия списка имён доменной зоны через NSEC в технологии DNSSEC. Хотя, DNSSEC пока что не имеет должного распространения.

Из имён .ru, корректно подписанных DNSSEC, для которых в DNS указаны записи TLSA (это технология DANE, дополняющая инфраструктуру SSL/TLS) – мне удалось найти только пять, вот они:

dxdt.ru
feuerplatz.ru
lexeyko.ru
megaid.ru
ojab.ru

Это из примерно 4,5 млн делегированных доменов. Мягко говоря, не слишком много.

С DNSSEC связано немалое число хитрых особенностей, которые не так очевидны, как базовые принципы этой технологии. Например, часто приходится сталкиваться с неверной трактовкой назначения DS-записи. Между тем, DS-запись (Delegation Signer) – важнейший элемент DNSSEC, так как с её помощью выстраиваются цепочки доверия. Эта запись указывает на ключ, который зона, расположенная на уровень ниже (делегируемая зона), должна использовать для удостоверения (подписывания) адресной информации.

Одна из хитростей состоит в том, что если в родительской (делегирующей) доменной зоне присутствует DS-запись для дочерней (делегируемой) зоны, и родительская зона безопасна (то есть, подписана DNSSEC), то это означает, что дочерняя зона тоже должна быть безопасной. То есть, валидирующий резолвер ожидает, что дочерняя зона содержит, во-первых, подходящие к DS ключи, нужные для проверки подписей, во-вторых – сами подписи на ответах об адресации внутри зоны. Соответственно, если DS-запись присутствует, а дочерняя зона не подписана, валидирующий резолвер будет возвращать сообщение об ошибке. Это совершенно правильное поведение, потому что иначе смысла в DNSSEC нет: подделать ответы без подписей не составляет труда; если резолвер не имеет возможности отличить подписанную зону от неподписанной по наличию DS-записи в доверенной (безопасной) зоне, то подписи можно вообще не проверять.

Другой важный момент: если авторитативный сервер родительской (делегирующей) зоны, подписанной DNSSEC, отвечает на рекурсивный запрос списком NS-ов и DS-записью, то подпись ставится только на значение DS. Казалось бы, нужно подписать и список NS-ов – как иначе узнать, что они правильные? Но если у нас есть доверенная DS-запись, то нет разницы, с каких серверов мы получим дополнительную информацию: главное, чтобы совпал ключ и его отпечаток в DS, а также сошлись значения подписей. Тут работает основной принцип DNSSEC: если данные об адресации аутентифицированы, то не имеет значения, из какого источника они получены.

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

Google Public DNS для зон, имеющих DS-запись, но не подписанных, возвращает ошибку (SERVFAIL), вне зависимости от того, какова природа этих DS-записей. Другие валидирующие резолверы ведут себя иначе. Например BIND, обнаружив неизвестный алгоритм генерации DS, считает, что DS-записи в родительской зоне вовсе нет (что не совсем корректно, но с практической точки зрения оправдано, и, конечно, соответствует рекомендациям RFC). Пример такого поведения можно наблюдать для зоны dotsu.su – здесь в .su специально указаны DS-записи с неизвестным алгоритмом (9).

(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в DNSSEC. Думаю, что описание заслуживает публикации на dxdt.ru – потому что до сих пор нередко путают ключи, зоны, цепочки делегирования и прочие важные моменты.)

Посмотрим на то, как используются ключи DNSSEC, взяв для примера зону .org. Предположим, что мы справшиваем SOA-запись для .org у корневого сервера. Тогда, вместе с адресами NS-ов домена org, если последний делегирован безопасно, то есть, с DNSSEC, мы получим от корневого сервера DS-запись (или несколько – сейчас, например, их для .org две) и RRSIG-запись для DS (важно – именно для DS). То есть, главная интересующая нас подпись содержится в корне, это RRSIG over DS (RRSIG от DS). Напомню, что DS-запись содержит значение хэш-функции ключа, относящегося к делегируемой зоне (то есть, в случае нашего примера, к .org). Подпись RRSIG сгенерирована при помощи корневого ZSK (Zone Signing Key, ключа подписи зоны), который опубликован в корневой зоне, и его нужно будет оттуда получить, чтобы проверить подпись на DS. (Ключ также может уже находиться в кэше резолвера, тогда запрашивать его у корневых серверов не нужно.)

В дальнейшем, информацию, полученную с сервера имён (NS) домена org, мы проверяем ключами, которые опубликованы в этой же зоне (в .org). То есть, RRSIG-и из данной зоны проверяются ключами, которые в той же зоне и расположены. Для связывания ключей из разных зон в цепочку доверия служат DS-записи, которые также подписываются.

Посмотрим чуть ближе на реальное устройство DNSSEC для .org, как всё выглядит сейчас:

1.

В корне (в корневой зоне) мы видим два ключа (я буду их обозначать реальными идентификаторами, которые я взял из DNS) – 22603 (ZSK) и 19036 (KSK – кстати, не менялся с 2010 года, потому что забыли придумать, как его поменять). Для ключа 22603 в корневой зоне есть RRSIG, сгенерированная от ключа 19036. 19036 – это и есть тот самый главный, корневой, рутовый KSK, открытая часть которого изначально находится у нас в резолвере (пусть ключ и опубликован в DNS, но в резолвер он должен попасть каким-нибудь другим доверенным путём, не черезе DNS). После того, как мы проверили RRSIG от ключа 22603 этой открытой частью ключа KSK (19036) и всё сошлось, мы добавляем ключ 22603 в доверенные ключи. И можем пойти дальше.

2.

В корне же мы видим DS-записи для ORG, а также RRSIG для них. Подпись (RRSIG over DS) сделана от ключа 22603 (то есть, от ZSK, см. выше). Ключ 22603 мы только что добавили в доверенные. Проверяем подпись на DS-записи, если всё сошлось, то можем пойти дальше, записав себе значение DS.

3.

На серверах, поддерживающих .org, мы видим четыре ключа – 9795, 21366 (эти два – KSK) и 60764, 11112 (а эти два – ZSK; KSK от ZSK отличаются значением одного бита в поле типа ключа). Хэш от ключа 21366 соответствует значению DS-записи, опубликованной в корне (см. выше). Эту запись мы только что (ну или некоторое время назад, см. TTL) получили от корневого сервера, вместе с подписью, которую проверили – значит, DS-у доверяем.

4.

На серверах .org мы также видим записи (их сейчас три) RRSIG для набора DNSKEY. Эти три записи RRSIG сгенерированы от трёх ключей: 9795, 21366 и 11112 – обратите внимание, каждая из этих RRSIG подписывает все ключи, опубликованные в зоне (ключи публикуются в записях DNSKEY). То есть, у нас четыре ключа подписаны при помощи трёх других. Один из этих подписывающих ключей – 21366 – соответствует DS-записи, полученной из корня, поэтому мы можем добавить его в список доверенных ключей. Теперь записям, подписанным этим ключом, мы тоже будем доверять. После того, как мы убедились, что подпись от ключа 21366, сделанная для RRSIG DNSKEY в зоне .org, – валидная, мы добавляем и три других ключа (9795, 11112, 60764) в список доверенных. Почему? Потому что RRSIG over DNSKEY удостоверяет и их тоже – она для всех ключей зоны общая.

5.

Итак, мы решили получить SOA-запись (это главная запись в любой DNS-зоне) от .org и проверить её. Нет ничего проще: получаем SOA, вместе с ней приходит RRSIG, сгенерированная от ключа 11112, этот ключ есть у нас в списке доверенных, поэтому проверяем подпись – если сходится, то верим данным из SOA-записи. (Аналогично – для А-записей и для прочих.)

Обратите внимание, что мы не проверяли подписи на адресах NS-ов (серверов имён .org) – этого и не нужно делать, если только мы не хотим проверить именно значения NS-ов. Хитрость в том, что в DNSSEC не имеет значения, откуда были получены подписанные данные – с легитимных серверов или ещё откуда-нибудь: главное, чтобы подписи сходились.

Резюме: информацию, получаемую с серверов .org, мы проверяем ключами, полученными с тех же серверов, а вот убедиться, что это правильные ключи, нам позволяет подпись (RRSIG over DS) из корневой зоны.

Собственно, добавил в зону dxdt.ru TLSA-запись, содержание которой соответствует отпечатку (SHA-256) серверного сертификата – это означает, что для dxdt.ru теперь заработала поддержка DANE (технологии, позволяющей с помощью DNSSEC защитить домен от подмены SSL-сертификата). Вот бы ещё DANE, наконец-то, стали поддерживать браузеры.

Для дистрибутива Fedora Linux планируют внедрение локального DNS-резолвера, валидирующего DNSSEC. Этот резолвер предлагается использовать по умолчанию. То есть, дистрибутив будет проводить проверку адресной информации непосредственно на клиенте, что обозначает завершающий этап развёртывания технологии DNSSEC. Естественно, только обозначает: потому что для окончания данного этапа – мы должны увидеть локальную валидацию по умолчанию в распространённых клиентских системах (ни Fedora, ни Linux к таким, к сожалению, не относятся).

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