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

Что касается использования LLM ИИ в качестве вспомогательного инструмента “для подготовки текстов”. Вообще, если речь про “составить типовой договор”, то такие задачи давно и успешно автоматизируются, но делается это так, что конкретная форма договора собирается из конкретных зафиксированных оборотов по шаблону, а пользователю нужно, например, ввести данные сторон. Это, хотя бы, работает без “галлюцинаций”, что составляет полезную особенность. То есть, генератор-синонимайзер “по цепочкам слов” иногда нужен, но не в этом случае.

Прочие формальные и не очень формальные тексты, связанные с какими-то выводами и заключениями, должны составляться в результате обдумывания положений человеком – в этом, вообще-то, смысл, хоть сейчас и повсеместно переходят к концепции “задача – нажимать Кнопку” (это же, кстати, касается и всякой “диагностики”). “Упрощение” работы с применением ИИ тут приводит к тому, что это LLM ИИ будет предлагать “решения”, описывая их произвольным образом в сгенерированном тексте, а пользователь, из-за эффективно популяризованного через СМИ нарратива, будет считать, что ИИ “выполнил исследование” и “компьютер не может ошибаться”. Это, конечно, не для всех хорошо, а польза тут совсем не в том ключе, в каком ожидается: поскольку решениями в реальности будет управлять провайдер сервисов ИИ.

В Ars Technica пишут, что The New York Times через суд пытается отключить сервисы OpenAI, которые СМИ продвигают как “интеллект” (пусть и искусственный). Названная причина: LLM, являющиеся синонимайзерами-переростками, копируют и используют контент NY Times для того, чтобы уводить у них аудиторию, а также порочить источники своими “галлюцинациями”. Причём, тема с приписыванием тому же NY Times выводов и комментариев, которые полностью сгенерированы LLM, рассмотрена отдельно. То есть, где-то всё же остались следы более или менее трезвого подхода, позволяющего видеть параллели между старинной методикой создания “дорвеев” различного типа при помощи пропускания через синонимайзер чужих текстов, собранных на веб-сайтах, и “обучением” современных LLM.

Когда обсуждают низкоорбитальные спутники, то нередко забывают, что это хоть и космический спутник, но, как точка наблюдения, он оказывается очень близко к наблюдаемой наземной территории: например, высота Starlink – около 550 км, а была и заявка на 340 км, ещё ближе. То есть, тот же Starlink, это такой универсальный орбитальный сенсор, построенный на тысячах спутников, который находится на дистанции, сравнимой с параметрами лучших из современных авиационных РЛС. И спутник может оказаться сильно ближе, чем способен подойти разведывательный самолёт или беспилотник.

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

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

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

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

Кстати, что касается помех: сеть пассивных орбитальных приёмников, если они используют достаточное разрешение по времени в схемах преобразования сигнала, позволит определять координаты источника помех, даже если сигнал – просто шум. Если же сигнал помехи имеет хорошо обнаруживаемую структуру, то задача упрощается. Понятно, что аналогичным образом можно использовать не помехи, а рабочие сигналы РЛС (и не только РЛС).

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

Так что сети низкоорбитальных спутников, типа сети Starlink, полезны не только и не столько для широкополосной радиосвязи.

Воскресное чтение манускриптов. Точнее – иллюстрация с пальмами и антилопой из “Христианской топографии” Козьмы Индикоплова, в варианте из Апостольской библиотеки Ватикана, датируемом девятым веком (н.э).

Подпись к иллюстрации утверждает следующее:

ΤΑΥΤΑ ΕΙϹΙ ΤΑ ΛΕΓΟΜΕΝΑ ΜΟΖΑ
ΟΙ ΦΥΝΙΚΕϹ ΟΙ ΪΝΔΗΚΙΝΟΙ

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

Кстати, есть весьма полезный пример, показывающий различие между формулами, компьютерами и интерпретацией формул. Его удобно приводить в качестве иллюстрации к объяснениям про “компиляторы, регистры, транзисторы и ячейки с битами”. Отчасти относится к предыдущей заметке. Сравним запись (a == b) с записью ((a – b) == 0). Например, в контексте записи и компиляции исходного кода на том или ином языке программирования: if (a == b) {…} и if ((a – b) == 0) {…} – известно, что результаты вычисления условий в таких if-ах на практике могут различаться; причём то, как именно они различаются, зависит и от языка, и даже от используемого системного окружения.

Наивная арифметическая логика тут такая: “a равно b, когда a-b == 0”. Но тут многое спрятано внутри. Во-первых, никто же не сказал, какого типа объекты a, b; во-вторых, не определено, что это за операция “-“; в-третьих, с равенством, как понятием, вообще говоря, тоже есть масса тонкостей. Так, в записи использован двойной знак равенства “==” – он означает какую-нибудь “эквивалентность”?

Знак “=” – один из самых сложных, с точки зрения машинной интерпретации. Собственно, поэтому и возникли “==”, “===”, “:=” и прочие сочетания. Вот если написано “f = m+n”, то что тут имеется в виду? Что “f” – это “формула” (или даже “функция”), имеющая вид _ + _? Или запись обозначает, что имя “f” нужно использовать как синоним для строки “mn”? Или это условие, которое обозначает проверку того, что число под именем “f” равно сумме чисел под именами “m” и “n”? Или какой-то другой вариант?

Можно предположить, что “==” это именно “равенство”. Но равенство объектов ещё нужно определить. Это не всегда просто. Особенно, для компьютеров. Особенно, если вы вынуждены использовать какие-нибудь представления с плавающей точкой – тут не только нули прекрасно расщепляются на разные представления, но и другие неожиданные эффекты постоянно проявляются (см. пример ниже). Конечно, наивный школьный подход предполагает, что “==” это, всё же, “простое и очевидное” равенство натуральных чисел, автоматически оснащённых сложением, умножением, и даже какими-то некоммутативными и разрывными вычитанием с делением. Что касается натуральных чисел, то, согласно распространённому мнению, тут-то вообще всё становится “очевидным” ещё после того, как в начальных классах про них много рассказали на примерах с палочками. Поэтому случается, что натуральные числа смело относят в разряд “самоочевидных феноменов”, с которыми работать умеют, якобы, даже вороны и, особенно, вороны (переключите ударение, если вы не LLM).

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

А ведь “==” может предусматривать неявное приведение типов при сравнении, что прямо относится к не менее школьным, хоть и некоммутативным, задачам про апельсины в ящиках (например). Потому и появляются “===”, а также и используемые в теоретической математике “:=”, означающие не столько “равенство”, сколько определение. Что же про вариант (a-b) == 0, то тут, как минимум, ясно, что требуется ввести много дополнительных соглашений, чтобы определить вычитание. Особенно, для строк. Но и без строк в компьютерном представлении возникнут новые, занимательные эффекты, иногда полезные, иногда – неожиданные.

Вот и вернёмся к языкам программирования и представлению чисел в компьютерах. Известно, что уже в языке Python попытка признать (a-b) == 0 и a == b эквивалентными наталкивается на тот самый, занимательный, эффект:

import math
a = math.pow(5, 55)
b = 5 ** 55

print(a == b)
print((a - b) == 0)

Эта нехитрая программа печатает следующий результат (Python 3.9, Debian 11):

False
True

Так что здесь a хоть и не равно b, но зато (a – b) равно нулю. Что происходит? Происходит вычислительное сравнение, на которое влияет представление чисел внутри Python, переполнение и автоматическое (неявное) преобразование типов:

a == 2.7755575615628914e+38
b == 277555756156289135105907917022705078125

– это, вообще-то, весь фокус, записанный “в формулах”. Соответственно, если возводить в степень 15, то программа напечатает True и True, что соответствует арифметическим ожиданиям. Аналогичный эффект (True, True) даст, по другой причине, следующий вариант:

import math
a = math.pow(5, 55)
b = 5 ** 55

print(a == float(b))
print((a - b) == 0)

За простыми на вид компьютерными формулами часто скрываются хитрые трактовки и скрытые структуры, которые хоть и подразумеваются, но это подразумевание бывает с двойным (“==”), а то и с тройным дном (“===”).

Занимательное программирование. Почему вместо первого фрагмента кода (см. ниже) предлагается писать второй фрагмент (см. ещё ниже)?

Первый фрагмент:

if(matched != 0)
	// passwords match
else
	//passwords don't match

Второй фрагмент:

if(matched == 0x69d61fc8)
	// passwords match
else
	//passwords don't match

Потому что так предлагается защищаться от дефектов аппаратуры, приводящих к переключению битов в результате rowhammer-атак. Примеры взяты из исходной работы, где соответствующие “гаджеты” (то есть, способы сравнения в if) для проверки реквизитов доступа обнаруживаются в OpenSSH, sudo и др. Логика, стоящая за словом 0x69d61fc8, такая: rowhammer позволяет при помощи интенсивных операций с ячейками памяти переключать биты в соседних (физически) ячейках; поэтому, если используется условие “не равно нулю”, то достаточно перещёлкнуть один произвольный бит в нулевом значении переменной, чтобы равенство нарушилось и “пароли совпали” (passwords match); условие же “равно 0x69d61fc8” (или ещё какому-нибудь “перемешанному” значению) перещёлкиванием битов подогнать “несколько сложнее”.

Вообще, с точки зрения “просто программирования”, вариант matched != 0 – верный, работает, его можно использовать, никакой проблемы тут нет. А вот если подойти с точки зрения информатики и потребовать учитывать дефекты аппаратуры, то != 0 вдруг оказывается подвержено проблемам “аппаратурной” оптимизации ничуть не меньше, чем реализации алгоритмов, использующие строго фиксированное количество операций (вне зависимости от значений битов входных данных – constant-time, но не перепутайте с соответствующим классом сложности). Впрочем, в отличие от атак, измеряющих сдвиги времени исполнения, управляемое перещёлкивание произвольных битов – это, конечно, никакая не физическая особенность, а именно аппаратный дефект. Исправлять его, как и многие похожие, предлагается программно, а исправление приводит к не самым очевидным эффектам в коде на языке высокого уровня (ЯВУ) – потому что выбор значений констант для флагов таким образом, чтобы они оказывались далеко друг от друга в смысле rowhammer-метрики, это не очень близко к логике ЯВУ, да и нужно учитывать, что оптимизирующий компилятор может всё переписать на те же нули, но уже в машинном коде.

(Описание на OpenNET.)

На сервисе audit.statdom.ru, в части тестирования настроек MX, добавился вывод сведений о совпадающих IP-адресах для разных имён MX-ов и чуть более развёрнутые сведения о TLS-сертификате почтового сервера (имя CN удостоверяющего центра).

Что касается разных имён для одинаковых IP-адресов, то тут речь вот о чём: предположим, что в зоне указано три имени MX – mx1.test.ru, mx2.test.ru, mx3.test.ru, но двум из этих имён соответствует общий адрес, например, mx1.test.ru имеет адреса 10.11.22.33, 10.22.33.44, а mx2.test.ru – 10.11.22.33, 10.55.55.55 (совпали 10.11.22.33). Это не то чтобы типовой случай, но регулярно встречается. Например, такое есть у Gmail. Причины тут могут быть разные, редко – это просто ошибка, а чаще – проекция представления администраторов и DevOps о методах балансировки (случай крупных сервисов) и защиты от нежелательных сообщений.

Кстати, с точки зрения сканера, конфигурация с повторяющимися IP создаёт некоторые занимательные затруднения для анализа TLS в случае STARTTLS. Дело в том, что ответы почтовых серверов кешируются, чтобы не надоедать “почтовикам” повторными запросами. Повторные запросы без попыток доставки сообщений – это, в мире администрирования почтовых серверов, самое страшное, что только может быть, так что робот к роботу тут должен подходить только с должным пиететом, расшаркиваясь и выжидая положенное время (посмотрите, кстати, на один из самых занимательных статистических отчётов по почтовым серверам Рунета – время ожидания ответа). Кешировать имеет смысл только по IP-адресу, потому что именно по IP-адресу устанавливается соединение. Так что, когда одинаковый адрес используется с разными именами, приходить повторно сканер не будет, но, вообще говоря, это означает, что сканер не сможет и получить сертификаты для разных имён, которые сервер, – гипотетически, – мог бы передать в ответ на не менее разные значения SNI (имя хоста в TLS).

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

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

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

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

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

DNSSEC предоставляет механизм удостоверения адресной информации в DNS, что требует подтверждения факта отсутствия ответа на запрос. Собственно, это особенность не столько DNSSEC, сколько любой подобной криптографической системы: необходима возможность криптографического подтверждения, что какие-то записи действительно отсутствуют, потому что иначе активный аткующий может просто удалить из DNS-ответов записи, обеспечивающие безопасное делегирование (DS-записи), тем самым сымитировав отсутствие DNSSEC в атакуемой зоне. Отсутствию записей и имён в терминах DNS соответствует NXDOMAIN (нет имени) и NODATA (нет данных записи запрошенного типа). NXDOMAIN – это когда спросили имя test.example.com, а его в зоне example.com нет. NODATA – спросили TXT-запись для test.ru, имя test.ru есть, но ему не соответствует TXT-записи (NODATA это ANSWER:0 со статусом NOERROR, если в терминах BIND).

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

Например, для NXDOMAIN “подписываются” два ближайших имени, между которыми оказалось бы запрашиваемое, если все имена в зоне упорядочить. Известно, что эта реализация позволяет третьей стороне проиндексировать имена, существующие в зоне, поскольку ответ на запрос со специально составленным несуществующим именем позволяет видеть соседние существующие имена – это называется DNSSEC zone walking (индексация зоны), и предоставляет хрестоматийный материал для обучения студентов направления “Информационная безопасность”, но не более. Строго говоря, есть два основных варианта решения проблемы “подписывания дыр”: они называются NSEC и NSEC3, а последний предоставляет больше защиты от индексации зоны, однако сейчас это всё лишь иллюстративные детали, поскольку вообще странно считать, будто заведомо публичные записи в зоне должны быть защищены таким странным способом от “обнаружения” – см., впрочем, про “принцип Керкгоффса“. Предложены способы, предотвращающие индексацию зоны путём “подставных” ответов, содержащих специально сгенерированные имена.

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

При полностью динамической работе DNS на стороне авторитативного сервера всякое противодействие индексации зоны требует динамических подписей. Однако в таком случае обработка NXDOMAIN быстро превращается в проблему, поскольку требуются дополнительные вычисления. Особенно, если в зоне много имён. Грубо говоря, если у вас есть миллион записей с именами хостов в некоторой базе данных, то уже для обнаружения соседних имён придётся строить какой-то индекс и так далее. Если же состав записей постоянно изменяется, а ответ зависит и от видимых характеристик клиента, и от текущего состояния большей системы на стороне сервера, то вычисление NXDOMAIN может вылететь в копеечку (в том числе, из-за большого размера ответа с подписями). Оригинальное решение тут первыми применили в Cloudflare, ещё в 2016 году. Решение основано на модификации логики обслуживания DNSSEC – предлагается, фактически, исключить понятие отсутствующего имени или отсутствующей записи, что позволит генерировать виртуальные подписи на лету (но, обратите внимание, это не отменяет кэширования сгенерированных ответов).

Иными словами – сервер выдаёт “нечестные” ответы. Например, сервер не отвечает резолверу со статусом NXDOMAIN вообще, а вместо этого использует вариант NODATA: на запрос о реально не существующем в зоне имени сервер отвечает, что есть имя, состоящее из префикса \000., приписываемого к запрошенному имени, то есть, это как бы граница (которой в реальной зоне нет), а ответ поэтому содержит одну NSEC-запись; подпись же вычисляется на лету. Для случая “настоящего” NODATA – всё работает аналогично: сервер отвечает, что есть все мыслимые ресурсные записи, кроме той, которую запросил резолвер. Например, если резолвер спрашивает A-запись, то авторитативный ответ будет содержать указание в NSEC на существование NS, SOA, TXT, LOC, SRV и прочих DNS-записей, но не A-записи. Это тоже позволяет генерировать ответы динамически. То есть, авторитативный сервер “обманывает” резолвер, но делает это для того, чтобы экономить вычислительные ресурсы (поэтому механизм называется black lie – вместо white lie, однако это детали литературной терминологии).

Всё это несложно сейчас увидеть снаружи на примере Cloudflare: попробуйте взять dig и проверить самостоятельно на той или иной зоне, поддерживающей DNSSEC на авторитативных серверах Cloudflare. Такая реализация не только позволяет работать с динамической DNS, но и экономит место в ответах (другой существенный способ экономии – ECDSA, которую только и использует Cloudflare, так как ECDSA-подписи короче RSA).

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

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

Кстати, если посмотреть в DNS-зону cloudflare.com (это, понятно, Cloudflare) на предмет политики DMARC, то там в поле rua указан почтовый адрес в cyber.dhs.gov:

$ dig -t TXT _dmarc.cloudflare.com +short
"v=DMARC1; p=reject; pct=100; rua=[...]mailto:reports@dmarc.cyber.dhs.gov"

Что это означает? Имя cyber.dhs.gov – это в Штатах агентство CISA (Cybersecurity and Infrastructure Security Agency), относящееся к DHS, то есть, к министерству внутренней безопасности (Department of Homeland Security). Опция rua в строке DMARC обозначает адрес (адреса), по которому принимающие почтовые серверы могут отправлять отчёты об обработке почтовых сообщений (допускаются разные протоколы для доставки, но обязательный – mailto, электронная почта). Так что, запись означает, что сборщик отчётов DMARC CISA может сразу принимать сведения о получении почты с адресами в домене cloudflare.com. Это не обязательно сообщения, действительно отправленные почтовой системой Cloudflare – может быть и нежелательная рассылка с “подспуфленным” адресом: для обнаружения таких писем как раз нужны DMARC и DKIM.

Немного про административную структуру, связанную с доменами верхнего уровня. Про эту структуру сейчас почему-то забывают, сосредотачиваясь на регистраторах, с которыми взаимодействует обычный пользователь. Однако, в современных интернет-реалиях, эта административная стурктура довольно важна. Домены верхнего уровня здесь – это имена зон, указанные в корневой зоне общепринятой (пока что) системы доменных имён (DNS): .COM, .NET, .RU, .PW, .BAR и др., их сейчас очень много, заметно больше 1500. Корневой зоной всё ещё управляет IANA под эгидой ICANN, но сейчас речь о другом. А именно: практически у всякого домена верхнего уровня есть обособленный администратор, технический контакт и оператор реестра. И это всё могут быть совсем разные организации. (Тут встречаются исключения, конечно, но весьма редкие: “потерявшиеся” зоны, “спорные” зоны, тестовые домены и так далее – эти случаи не рассматриваем.)

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

Административные и технические роли в доменах верхнего уровня могут пересекаться неожиданным образом. Например, что общего у доменов .PW и .BAR? Администраторы – разные. Технические контакты – разные. Даже класс домена отличается: .PW – это домен ccTLD (национальный), а .BAR – это New gTLD (домены, добавленные в DNS силами ICANN в рамках процесса “массового расширения”). Поэтому далеко не всякий продвинутый интернет-пользователь знает, что за этими разными доменами стоит один и тот же провайдер сервисов реестра: компания CentralNic (это, впрочем, и не скрывается).

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

Что это всё означает? Это означает, что если оператор реестра того или иного домена верхнего уровня станет что-то блокировать (по указанию администратора домена или без такого указания), то он может заблокировать передачу регистраций с конкретными данными регистрантов (администраторов доменов уровнем ниже). И регистратор с этим не может ничего сделать. Собственно, регистратора могут просто отключить от реестра, а доменные имена, которые через него зарегистрированы, передать другому регистратору, снять с делегирования (то есть, они не будут доступны в DNS) и перевести в статус “заблокированных”, переделегировать произвольным образом, или просто удалить – вариантов тут масса.

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