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

Тема противодействия надоедливым любительским беспилотникам, всё чаще заглядывающим в окна, не новая. Например, про беспилотники-охотники я писал несколько лет назад, а в прошлом году – обсуждали захват беспилотника сетью и спуск его на парашюте. Появляются новые проекты. Так, предлагают следующую концепцию: охотник заводит в пропеллер атакуемого дрона линь (тонкий тросик или ленту), который наматывается на лопасти, тем самым останавливая один из двигателей; испорченный дрон – падает (подробности по ссылке на IEEE Spectrum). Такой метод, конечно, может привести к тому, что потерявший управление дрон куда-нибудь врежется и что-то сломает. Но самое интересное, что, как и отмечено в IEEE Spectrum, появление таких перехватчиков приведёт к тому, что любительские дроны будут оборудованы средствами защиты (пассивной и активной). Ну или станут летать парами – исследователя с видеокамерой прикрывает истребитель, атакующий охотников.

Вообще, от тросика не так сложно защититься, закрыв пропеллеры сеткой: достаточно прикрыть их сверху. Кроме того, дрон может быть снабжён программой ухода от перехватчика. Вовсе не обязательно использовать метод быстрого набора высоты: наоборот, атакуемый беспилотник способен пойти на снижение, с интенсивным маневрированием, и, таким образом, избавиться от угрозы контакта тросика с собственными винтами. Не сложно придумать и другие варианты. Схватка роботов в воздухе наверняка окажется интересной.

На сайте Алекса Экслера читаем, что при работе с почтой (предоставляемой в домене exler.ru), теперь есть HTTPS, но нужно игнорировать предупреждение безопасности браузера:

Почта на Exler.ru теперь работает по HTTPS-протоколу с самоподписанным сертификатом. Системы безопасности в браузерах на самоподписаный сертификат будут ругаться – предупреждаю. Поэтому надо адрес mail.exler.ru занести в исключения (доверенные сертификаты) – тогда ругаться не будет.

(Сертификат там, кстати, отдаётся не самоподписанный, но это детали.)

Именно так приучают массового пользователя к тому, чтобы он, фактически, игнорировал HTTPS, убивая этот протокол. Дело в том, что призыв игнорировать предупреждения и добавлять исключения, делает HTTPS близким к открытому HTTP, в плане перехвата трафика. Потому что в XXI веке настроить SSL-прокси не так уж и сложно. Естественно, главное отличие, в смысле перехвата, остаётся: для чтения HTTP достаточно пассивного “снифера”, HTTPS потребует активной подмены узлов. Но приучать пользователей давить кнопку “Всё равно продолжить” (название условное) – это совсем нехорошо. (Признаваемый браузерами сертификат стоит не так дорого, можно ещё найти бесплатные, а уж для exler.ru, думаю, кто-нибудь просто подарил бы сертификат.)

На сайте Spiegel Online опубликован (PDF) занятный документ британского Центра правительственной связи (GCHQ – это спецслужба, занимающаяся, в том числе, радиоэлектронной разведкой). Документ, – конечно, полученный от Сноудена, – описывает технологию, которую рекомендуют применять для деанонимизации пользователей сети TOR. Технология, впрочем, известная, основанная на корреляции параметров трафика на входном и выходном узлах сети. Конкретно – используются временные параметры.

Напомню, что TOR, для анонимизации, использует цепочку из узлов, пересылающих зашифрованный трафик. С цепочкой всегда связаны входной (“начальный”) и выходной (“оконечный”) узлы. Внутри сети TOR пользовательский трафик зашифрован, “вложенным” шифрованием. Известно, что параллельный анализ трафика, наблюдаемого на входном и выходном узлах (то есть, трафика, входящего в TOR и выходящего из этой сети), позволяет деанонимизировать источник трафика. Деанонимизация здесь сводится к определению внешнего IP-адреса пользовательского узла. Трафик можно собирать либо специальными средствами мониторинга, либо при помощи собственного выходного узла. Важно заметить, что выходной трафик не обязательно собирать непосредственно на выходном узле. Можно записывать TOR-трафик (который несложно выделить) непосредственно на сетях провайдеров, у которых размещаются посещаемые веб-сайты.

Собственно, методика известная (я, например, писал о ней в осеннем выпуске журнала “Доменные имена“), применяемая на практике, и не только в Великобритании, что подтверждает новая публикация “секретных документов” (датированных, кстати, 2011 годом). Более продвинутый вариант этой технологии деанонимизации TOR использует для построения сигнатур дополнительные параметры записываемого трафика. Между прочим, деанонимизацию можно проводить постфактум, используя ранее записанные сигнатуры. Весь трафик сохранять не требуется: как обычно, само использование TOR автоматически поднимает нужные флаги, выделяя интересующий поток из общего массива данных, идущих через узел мониторинга.

Ещё несколько лет назад сайт, доступный только по HTTPS, мог оказаться вне зоны действия различных поисковых роботов, которые по HTTPS не умели страницы извлекать. Сейчас это не так. Я посмотрел в логи веб-сервера dxdt.ru и выбрал (произвольно) записи от нескольких ботов, чтобы определить, какие протоколы и шифронаборы они используют. Вот результат:

Googlebot/2.1 – “TLSv1 ECDHE-RSA-AES256-SHA”
bingbot/2.0 – “TLSv1 ECDHE-RSA-AES256-SHA”
YandexBlogs/0.99 – “TLSv1 DHE-RSA-AES256-SHA”
YandexBot/3.0 – “TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384”
Mail.RU_Bot/2.0 – “TLSv1 DHE-RSA-AES256-SHA”
SputnikBot/2.3 – “TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384”
YandexImageResizer/2.0 – “TLSv1 DHE-RSA-AES256-SHA”
sukibot_heritrix/3.1.1 – “TLSv1 ECDHE-RSA-AES256-SHA”
R6_CommentReader – “TLSv1 ECDHE-RSA-AES128-SHA”
rogerbot/1.0 – “TLSv1.1 ECDHE-RSA-AES256-SHA”
linkdexbot/2.0 – “TLSv1.2 ECDHE-RSA-AES128-SHA”
AhrefsBot/5.0 – “TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384”
MJ12bot/v1.4.5 – “TLSv1 ECDHE-RSA-AES256-SHA”
DotBot/1.1 – “TLSv1 DHE-RSA-AES256-SHA”

То есть, никаких проблем с обходом сайтов по HTTPS у ключевых для Рунета ботов – нет. Формально, из крупных ботов, “Яндекс” – самый прогрессивный, в смысле поддержки протоколов: тут мы видим TLSv1.2 и AES в режиме GCM (что, собственно, ожидаемо). Не подкачал даже SputnikBot – тут тоже все суперсовременно. Естественно, в случае с ботами, используемые шифронаборы мало на что влияют, да и вряд ли могут рассматриваться как определяющий показатель, особенно в современной структуре Веба. Но зато можно сказать, что работающие по HTTPS сайты, даже если они используют современные настройки TLS, вполне себе доступны для индексации самыми значимыми поисковыми машинами. Это означает, что можно смело переходить на HTTPS, не опасаясь, что боты не доберутся до контента.

Поделюсь настройками TLS на веб-сервере dxdt.ru. Я использую связку Apache+mod_ssl (стандартное решение). Важнейшие параметры – это используемые протоколы, “шифронаборы” (Cipher Suites – часто переводят как “наборы шифров”), а также их приоритет. Например, сейчас не рекомендуется использовать SSLv3 (и более ранние версии, которые, конечно, экзотика, но всё ещё встречаются в “живой природе”). Соответственно, в ssl.conf (файл конфигурации mod_ssl) для хоста dxdt.ru указаны следующие строки:

SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite “EECDH+AESGCM EDH+AESGCM EECDH+AES EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4”

Первая директива (SSLProtocol) разрешает только TLS (в трёх версиях, как несложно догадаться). Протоколы семейства SSL – не поддерживаем. Вторая директива (SSLHonorCipherOrder) указывает, что mod_ssl должен использовать приоритеты наборов шифров, заданные сервером (а не клиентом, то есть браузеру не удастся навязать свои предпочтения).

Директива SSLCipherSuite – это самое сложное место в настройках. Она определяет допустимые криптографические наборы (“шифронаборы”: алгоритмы обмена ключами и аутентификации, шифр, режим шифрования, алгоритм дайджеста). Условные имена наборов разделены пробелами. Конкретный набор согласуется клиентом и сервером во время установления соединения. Если договориться о подходящем наборе не удалось – TLS-соединение не устанавливается (именно это и происходит в случае IE8 под Windows XP).

В mod_ssl используются сокращённые имена для обозначения групп шифронаборов. Например: EECDH+AESGCM означает, что для генерации сеансового ключа будет использоваться алгоритм Ephemeral elliptic-curve Diffie-Hellman (разновидность алгоритма Диффи-Хеллмана на эллиптических кривых), а в роли алгоритма шифрования выступит AES в режиме GCM (Galois/Counter Mode – Режим счётчика с “аутентификацией Галуа”: один из современных “продвинутых” режимов блочных шифров, обеспечивающий, в том числе, аутентификацию данных; Галуа там возникает потому, что алгоритм аутентификации работает в конечном поле).

Сайт dxdt.ru использует серверный сертификат с ключом RSA; соответственно, аутентификацию сеансовых ключей можно проводить только при помощи криптосистемы RSA. Это некоторым образом экономит нам пространство в конфигурационной строке mod_ssl: вовсе не обязательно вписывать туда подробные указания вроде EECDH+ECDSA+AESGCM, как нередко рекомендуют, – DSA всё равно не поддерживается.

Несложно догадаться, что подстроки в SSLCipherSuite, начинающиеся с ‘!’, обозначают запрет на использование определённых криптосистем или криптографических примитивов. Всегда полезно прямо запретить заведомо неподходящие алгоритмы. Отмечу, что, в соответствии с современными традициями, запрещён RC4 (хотя он всё равно не предлагался бы сервером с указанными шифронаборами – не подходит).

Update (23/12/2014): в комментариях подсказали изящный вариант, с отключением всего ненужного одной директивой -ALL в SSLCipherSuite; такой вариант требует более точного описания шифронаборов, но зато он лаконичен:

SSLCipherSuite “-ALL:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES”

(Обратите внимание, что пробелы заменены на двоеточия.)

В HTTP-ответ добавлено поле HSTS (HTTP Strict Transport Security – требование “принудительной безопасности” для HTTP):

Header add Strict-Transport-Security “max-age=15552000”

Данное поле означает, что, грубо говоря, браузер должен запомнить, что к данному сайту доступ необходимо осуществлять только по HTTPS, в течение времени, указанного в параметре max-age поля HSTS. Это позволяет защититься от множества атак, основанных на подмене протокола HTTPS на HTTP.

Вот. Так работает TLS на dxdt.ru.

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

Неясно, как так могло получиться, но атаковавшим ICANN удалось получить администраторский доступ к некоторым сервисам. Это удивительно потому, что авторизация в системах подобного уровня должна бы быть защищена от простого перехвата почты сотрудников. Хотя, конечно, никто не застрахован от ошибок. В итоге, из сервиса Centralized Zone Data System – это полезный инструмент, позволяющий получать файлы зон доменов New gTLD, – утекли контактные данные пользователей, а также пароли, но в хэшированном виде.

(Кстати, самое громкое дело было бы, если бы у ICANN, а точнее – у IANA и VeriSign, утянули бы секретный корневой ключ KSK от DNSSEC. Понятно, что, в текущей ситуации с поддержкой DNSSEC, катастрофы бы не случилось, но случай был бы весьма показательный. Дело в том, что до сих пор не разработана процедура ротации корневого ключа KSK, так что DNSSEC, разве что, оставалось бы просто выключить.)

С 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).

Пять лет назад, когда твёрдотельные накопители данных (SSD) ещё не были настолько распространены, я писал о том, как быстро и надёжно уничтожить жёсткий диск – чтобы практически невозможно было восстановить записанные данные. Интересно, что та же самая немудрёная технология – пара ударов молотком – должна бы неплохо подходить и для SSD-накопителей. Вот только стучать придётся больше: потребуется разбить достаточное число чипов, которые хранят данные.

Хотя, многое зависит от схемотехники и логической организации накопителя. Удачное попадание молотка может выбить сразу кучу байтов (или хотя бы битов), соответствующих разным участкам большого файла. Но это если попадание удачное. В противном случае, если удалось восстановить карту размещения блоков, можно будет собрать много полезного из уцелевших элементов. Понятно, что данные о местоположении блоков и их отображении в последовательную структуру файлов – это самые важные данные. Предположим, что у нас полностью сохранён файл, имеющий объём в 100 мегабайт, но этот файл разрезан на небольшие блоки, которые перемешаны – как собрать их обратно, соединив в нужной последовательности? Особенно сложно проделать такую операцию для зашифрованного файла. Тем не менее, не исключено, что пары ударов молотка может не хватить – всё зависит от архитектуры накопителя.

Сети GSM – глобальны. Каждый абонент (SIM-карта) имеет уникальный идентификатор – IMSI. Если использовать возможности крупного оператора GSM, то можно “заходить” в чужие сети, находящиеся в других государствах, в рамках подключений и обмена данными, которые необходимы для межсетевой маршрутизации (звонки в роуминге и тому подобные вещи). Существуют базы данных, в которые включены едва ли не все базовые станции GSM, с привязкой к географическим координатам. Такие базы добровольно собирают сотни миллионов смартфонов по всему миру.

Конечно, продвинутые спецслужбы имеют доступ (легальный и не очень легальный) к служебному трафику операторов связи, опять же, по всему миру. Такой доступ позволяет получать информацию о регистрации телефонов в сети и другие, не менее полезные, сведения. Например, у АНБ, вероятно, есть весьма полные базы данных по всем мировым операторам связи – их оборудованию, адресному пространству, топологии сети и так далее (пример документа по теме – PDF, 27 MB).

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

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

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

Примерно две недели назад я полностью заменил для dxdt.ru протокол доставки веб-страниц на HTTPS. Самое время поделиться первыми впечатлениями. Во-первых, объём пользовательского трафика (посещений страниц) не изменился – не вырос, но и не упал. Мне предсказывали небольшое падение трафика за счёт изменений в индексах поисковых машин. Этого не заметно (насколько вообще что-то можно заметить в том весьма скромном трафике с поисковиков, который есть на dxdt.ru).

Во-вторых, нагрузка на сервер выросла, Apache ест несколько больше памяти, но виртуальная машина из Amazon EC2, как и прежде, вполне себе справляется. То есть, тут проблем нет. Однако время загрузки веб-страниц увеличилось, хотя и осталось в разумных пределах (менее секунды). Виной здесь не столько переход на HTTPS, сколько то, что в результате этого перехода поломался полезный плагин для WordPress: W3 Total Cache. Этот плагин заметно сокращал время генерации страниц CMS, за счёт кэширования (в Memcached). После замены протокола, кэш на сайте перестал автоматически сбрасываться при добавлении новых заметок, приходилось передёргивать его руками. В деталях я пока с этим явлением не разбирался, а просто удалил плагин, что, собственно, и привело к замедлению работы сайта.

В-третьих, с SSL-сертификатом COMODO, выпущенным от корня AddTrust CA через пару промежуточных сертификатов, возникли некоторые проблемы. По неясной мне причине, браузер Safari под Mac OS на некоторых “макбуках” данному сертификату доверять отказывается: в списке доверенных корней этой линейки браузеров нет подходящего корня (AddTrust или чего-нибудь иного, но с тем же ключом, да). Я уверен, что на сервере у меня всё правильно настроено: отдаются и серверный, и необходимые промежуточные сертификаты. Что происходит с некоторыми образцами программно-аппаратных продуктов компании Apple – ещё предстоит разобраться (у меня нет “макбука” – значит, для тестов мне нужно его у кого-то отобрать, да ещё и в подходящей комплектации). Замену SSL-сертификата, тем не менее, пока не планирую.

(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в 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) из корневой зоны.