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

Кто-то опубликовал черновик (draft) с описанием IPv8, очевидно, сгенерированный при помощи LLM: там во первых же строках предлагается аутентификация узлов с OAuth2, JWT-токенами, “из локального кеша”, и валидация каждого интернет-пакета через специальный DNS8 – дальше же можно не читать черновик, не тратить время. Печально, но теперь пишут на профильных сайтах, что это “организация IETF” выставила “черновик новой версии протокола IP”. Однако на странице данного черновика прямо, на специальной плашке, написано, что IETF никак данный черновик не поддерживает: “This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process”. Что, конечно, не удивительно: потому что не требуется одобрение и поддержка IETF для публикации черновика – кто угодно может опубликовать черновик.

Благодаря влиянию ACME и Let’s Encrypt, сейчас стала очень популярной схема подтверждения права управления доменом (DCV) через DNS, но при помощи размещения CNAME-записей. Речь про запрос TLS-сертификатов средствами автоматизации – скриптами (acme.sh, certbot и др.). Напомню, что DCV здесь состоит в проверке размещения TXT-записи с кодом подтверждения под заданным именем в DNS-зоне (это метод DNS-01). ACME использует специальный префикс: _acme-challenge.

Однако CNAME – это не TXT-запись, а способ перераспределить проверку в другую DNS-зону (см. детали ниже). Вообще, протокол ACME в данном сценарии не требует ни использования, ни даже поддержки CNAME. Но такая поддержка массово используется, и её сейчас принято обосновывать тем, что можно, мол, “не предоставлять доступ к исходной зоне скриптам автоматизации”. Использование CNAME – вообще плохая практика, а особенно плохая практика – это использование CNAME в процессе DCV. Что, конечно, не мешает массовому распространению. Вообще, с подобным использованием CNAME, – то есть, в DCV, – связана пара занятных технических моментов, о которых забывают.

Момент первый: постоянно путают синоним (алиас) и основное имя в CNAME. Дело в том, что CNAME – это Canonical NAME (каноническое имя), и каноническим является именно значение записи, а не имя-носитель. Имя-носитель – это и есть алиас, что бы там ни писали в инструкциях к средствам автоматизации ACME. Если для example.com в CNAME-записи указано 1.2.3mega-blah-blah.example.net, то вот это вот 1.2.3mega-blah-blah.example.net и есть основное имя. При использовании в ACME предлагается настроить CNAME для префикса _acme-challenge. Например, _acme-challenge.example.com в 1.2.3mega-blah-blah.example.net. Но и тут алиасом, в терминах DNS, будет _acme-challenge.example.com, префикс не влияет на отношение значений записей. Такова семантика CNAME.

Соответственно, получается, что проверка проводится для другого имени, не для того, которое указано в ACME-аккаунте при запросе DCV. Сертификат, в итоге, выпускается для одного имени, а проверка – фактически пройдена для совсем другого: для той зоны, которая назначена канонической при помощи CNAME. Дело в том, что CNAME-запись, при интерпретации резолвером, должна приводить к перезапуску процесса рекурсивного опроса для канонического имени, то есть, для значения из CNAME. Да, может показаться, что это технические придирки: всё равно же CNAME-запись должна быть размещена в исходной зоне, совпадающей с именем из DCV. Но нет, не так тут всё просто: CNAME может показывать на совсем другую зону, контроль над которой позволяет проходить DCV и выпускать сертификаты для прочих имён, в том числе, алиасов может быть много – это каноническое имя, по определению, одно. Если домен канонического имени (того, куда указывает CNAME) будет утрачен, переделегирован-перехвачен, или ещё что-то, то это административное изменение прямо коснётся авторизации TLS-сертификата для исходной зоны-алиаса. Происходит подмена самой сути DCV.

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

Момент второй: реальный доступ к зоне. Из первого момента, с каноническим именем, легко выводится этот второй: да, использование CNAME предлагают в качестве решения проблемы “расползания реквизитов доступа”. Мол, не хочется давать скриптам ACME доступ к редактированию нашей важной доменной зоны, поэтому пропишем CNAME и дадим доступ в другую зону, не такую важную. Но, как бы, смысл DCV – проверка права управления доменной зоной, а тут – это право управления прямо предлагают не выдавать, а подменить саму зону средствами DNS. Опять же, такая трактовка – не “перегиб”: дело в том, что управление зоной должно, если по-хорошему, подтверждаться при каждом выпуске сертификата (ну, хорошо, с некоторым интервалом по времени действия успешной проверки), а CNAME, направленная на каноническое имя – это долгий и универсальный вариант, не привязанный к выпуску сертификата вовсе. Для чего, собственно, использование CNAME и затевается. Опять противоречие.

Кстати, тут полезно вспомнить, что есть и суперновая версия DNS-проверки в ACME – с “постоянной” привязкой ACME-аккаунта к имени: вот где совсем не место CNAME (но черновик RFC пока что их не запрещает явно).

CNAME-записи – одни из самых сложных по поведению в DNS, а их использование – источник неожиданных проблем. В случае DCV, семантика и принципы интерпретации CNAME вообще противоречат основной логике проверки права управления через DNS. Что касается других решений: во-первых, ACME-префикс можно делегировать на отдельные NS, без всяких CNAME; во-вторых, для размещения TXT-записей вовсе не обязательно передавать полные права управления DNS-зоной каким-то скриптам. Это всё решения на стороне, заказывающей DCV. Но самое правильное, конечно, это не следовать CNAME при проверке DCV на стороне систем УЦ.

В рамках “ренейминга”, связанного с миграцией сайта с доменов .ru, сделал субординатные имена авторитатвиных серверов DNS для dxdt.blog. “Субординатные” – означает, что имена авторитативных серверов (NS) находятся в той же зоне, которая делегирована на эти серверы: например, ns1.example.com, ns2.example.com для example.com. Такую схему именования ещё иногда называют “красивые NSы”. В случае dxdt.blog, имена NS-ов – в зоне dxdt.blog.

Соответственно, делегирующий ответ с такими именами обязательно содержит так называемые glue-записи – то есть, записи с информацией об IP-адресах NSов. Иначе рекурсивный опрос не будет работать, так как зациклится. Я об этом писал неоднократно, в том числе, про сложную рекурсию, связанную с перекрёстными зависимостями.

Например, сама зона .blog размещена на NS-ах с субординатными именами:

alex@garlic-crusher:~$ dig blog. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
blog.			172800	IN	NS	a.ns.nic.blog.
blog.			172800	IN	NS	d.ns.nic.blog.
blog.			172800	IN	NS	c.ns.nic.blog.
blog.			172800	IN	NS	b.ns.nic.blog.

;; ADDITIONAL SECTION:
[...]

– здесь имена авторитативных серверов в ns.nic.blog., пусть для корневой зоны это и не имееет большого значения (см. ниже). Да, субординатные имена популярны, однако мне подобная схема именования не очень нравится. Другой вариант, из зон верхнего уровня, можно наблюдать в .ru:

alex@garlic-crusher:~$ dig ru. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	d.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	e.dns.ripn.net.

;; ADDITIONAL SECTION:
[...]

Однако, если говорить строго, то окажется, что любое имя в глобальной DNS Интернета так или иначе связано с “субординатными” NS-ами: потому что в делегирующих ответах, в качестве основного состава, могут быть только хостнеймы – имена серверов, и в какой-то момент рекурсивного опроса DNS обязательно возникнет проблема “курицы и яйца”. Более того, в DNS наступление такой проблемы можно откладывать до уровня корневой зоны, но вот IP-адреса серверов корневой зоны – распространяются по рекурсивным резолверам тем или иным способом, отличным от DNS (исторически – это всем известный hints-файл), именно для того, чтобы система заработала при первоначальном запуске.

Из Cloudflare пишут, что график полного перехода на постквантовые криптосистемы – сдвигается ближе: конкретно в Cloudflare планируют на 2029 год (это через три года). Напомню, что сейчас уже основная часть TLS-трафика в вебе защищена с использованием криптосистем обмена сеансовыми ключами с постквантовой стойкостью (ML-KEM, прежде всего). Но это симметричные ключи, для шифров. При полной же замене – речь идёт о защите схем аутентификации узлов. На этом направлении пока ничего в вебе не внедрено массово.

Конечно, в том же официальном блоге публиковали некоторые сомнительные заявления и про “успешный” “вайб-кодинг” сервера Matrix, поэтому приходится к указанным датам относиться с особенной осторожностью, пусть это и Cloudflare. С другой стороны, в области постквантовой криптографии ситуация сейчас более строгая – заявления ближе к реальности.

Самое интересное в озвученных планах, что на середину 2027 года (следующий год) запланирована защита постквантовыми криптосистемами цепочки аутентификации для подключающихся клиентов – это, как указано, сертификаты на хеш-деревьях (с ML-DSA, скорее всего). (MID 2027: PQ authentication support for visitor → Cloudflare connections using Merkle Tree Certificates.)

В Google недавно намекали на то, что поддержка постквантовых криптосистем подписи для TLS и X.509-сертификатов появится в Chrome/Chromium уже к концу 2026 года. И в это можно поверить, потому что сами технические средства в виде программного кода и описаний структур – довольно давно готовы, а полная реализация имеющимися средствами конкретно для TLS-сертификатов неоднократно продемонстрирована на практике.

И тут, конечно, напрашивается следующее наблюдение: переход на криптосистемы и на сертификаты нового типа на стороне крупнейших провайдеров, на стороне самых распространённых браузеров – тут же “превращает в тыкву” все имеющиеся подходы на стороне УЦ для веба.

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

Что вообще нужно для перехода на постквантовые криптосистемы в этом технологическом контексте? Понятно, что веб-TLS здесь является локомотивом. Понятно, что нужна подержка на серверной стороне – а это обещает и Cloudflare, и Google (другие, начиная с Microsoft, скоро подтянутся – не сомневайтесь). Понятно, нужна поддержка в браузере – это обещает, на это намекает Google (вообще, тут – именно обещает, потому что эксперимент Cloudflare и Google по вндрению сертификатов на хеш-деревьях – уже идёт). Остаётся поддержка на стороне УЦ, да. Но и Cloudflare, и Google – это УЦ: и “фактически”, и “практически”.

Да, нужна поддержка на стороне обычных серверов, в виде утилит для выпуска ключей и запросов на сертификаты всеми желающими. То есть, обычный сейчас вариант с ECDSA или RSA – не подходит: эти криптосистемы не обладают постквантовой стойкостью, теряется смысл даже в том случае, если УЦ подписывает постквантовой криптосистемой. Вручную же ключи генерировать могут не все, а тем более – использовать в веб-сервере. Нужны автоматические утилиты. Однако, распространение ACME-автоматизации – certbot и пр. – позволяет процесс автоматизировать и тут, сведя весь переход к обновлению версий системных библиотек и скриптов для заказа сертификатов через ACME. И веб-сервер придётся обновить, конечно.

В общем, не выглядит неральным, но посмотрим.

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

Что касается таких “утечек”, то это, естественно, очевидный момент; попытка же представить тут центральный сервер неким гарантом – очередная подмена самой концепции “защищённого обмена сообщениями”.

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

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

В свежей версии 149 браузера Firefox добавлен встроенный VPN-сервис, заворачивающий трафик к веб-узлам в туннель, проходящий через “прокси-сеть” Mozilla. Такой сервис был обещан некоторое время назад, теперь его постепенно внедряют в основную ветку браузера.

Тут как раз очень важно то, что вся обработка и перенаправление трафика – происходят в браузере. То есть, веб-узел видит только IP-адрес оконечного узла туннеля. А промежуточные сетевые узлы, находящиеся между браузером и входным узлом наложенной “прокси-сети”, не видят IP-адрес веб-узла, с которым соединяется браузер. Добавьте сюда защищённый DoH/DoT резолвинг DNS и – получается закрытая специализированная сеть доступа, привязанная к браузеру. Но пока что такой VPN-доступ не для всех, а только для пользователей в США, Великобритании, Германии и Франции.

Кстати, на d-russia.ru – сообщение про новые правила (проект) регистрации доменных имён .RU, .SU, .РФ. Если прочитать сами правила, то там, как и ожидалось, буквально везде требуется идентификация через ЕСИА, даже для делегирования имени, не то что при регистрации, продлении регистрации или при передаче права управления.

Когда-то, благодаря старому регистратору RU-CENTER, издавался такой замечательный, уникальный журнал – “Доменные имена”. Журнал выходил в печатном варианте, оформляли и верстали его, ни много ни мало, а в Ателье “Афиши”. У журнала был собственный заказной шрифт, особая бумага и удивительный дизайн каждого номера. А я некоторое время был главным редактором, так что хорошо помню процесс. Нынче даже и сайт журнала уничтожен (до сих пор не могу понять – почему).

Но сейчас не об этом.

Вот в 2012 году мы с Артемием Ломовым написали для этого журнала (ДИ, 2012/1(6)) занятную статью – “Сценарии конца Интернета”. Я на эту статью несколько раз уже ссылался на dxdt.ru. Интересно, что некоторые моменты из статьи стали сбываться, – частично, конечно, – прямо на следующий год после публикации. Например, сценарий про “Красную кнопку”. В статье упомянуты и “белые списки”, правда – в контексте “борьбы за копирайт”. В общем, дальше – пошло и поехало.

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

А вот чего нет в той статье, так это про сценарий с разгулом псевдо-ИИ на LLM, который мы сейчас наблюдаем. Разгул – с последующим уничтожением, как минимум, веба, путём затопления бредом, сгенерированным роботами для роботов. Ну, как – нет. Чтобы вот сказать, что прямо в точку – такого нет. А если вообще, про генераторы текста и затопление, то такое есть. Но немного в другом контексте. Цитата:

“А возможно, никакой технологической сингулярности не случится: как мы разобрались, есть угроза утраты человечеством инженерных навыков, поэтому разумные машины строить будет некому. В таком случае люди могут просто заскучать от «всех этих ваших интернетов», потерять интерес к компьютерам — и в результате мягкого глобального помешательства Сеть больше не нужна никому, сайты заброшены и не обновляются, замерз на ленте последний твит никому не известного жителя Техаса. Некоторое время разнообразные спам-боты и генераторы контента еще продолжат наполнять базы данных бессвязным текстовым бредом, предназначенным для чтения роботами поисковых машин, но потом потухнет и эта активность.

Опустевший Интернет завершил существование.”

Одно печально – когда мы эту статью писали, 14 лет назад, то сложно было представить, что реализовываться будет не один какой-то сценарий, а сразу все, параллельно. Видимо, чтобы наверняка.

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

Кстати, прошлый заход “борьбы с Telegram”, который был весной 2018 года, привёл к тому, что сайт dxdt.ru был довольно длительное время недоступен из сетей российских провайдеров (Telegram, конечно, продолжал работать).

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

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

Кстати, вот ещё из очевидного “творчества” ИИ/LLM – попалось на “Хабре” (где, похоже, результатов генерации LLM, – “ИИ-помоев”, – только становится больше), дословная цитата:

“TXT-запись — это произвольная строка текста привязанная к домену. Придумали её для SPF (верификация почтовых серверов) и DKIM, потом стали использовать для подтверждения владения доменом в Google Search Console и Let’s Encrypt.”

На минуточку: TXT-записи – описаны в RFC 1035, это 1987 год, однако сама концепция размещения TXT-записей – ещё старше. Никакого SPF, – а тем более, DKIM, – тогда ещё не было, и никто не придумывал TXT-записи для SPF и DKIM.

SPF (эта технология оформилась в начале 2000-х годов, TXT-записи уже были) – вообще первоначально использовала отдельный специальный тип DNS-записи (SPF-запись), который сейчас отнесён к устаревшим, а данные SPF, действительно, сейчас размещаются в TXT-записях, но из этого не следует, что TXT-записи “придумывали для SPF”. DKIM – та же история, только ещё более свежая, из 2007-2011 (исходный документ RFC 4870 – это 2007 год, но данный RFC сейчас имеет статус “исторического” и не применяется).

Ну и забавно выглядит утверждение, что “потом стали использовать для подтверждения владения доменом” – то есть, вообще не верно: подтверждение с помощью TXT-записи применялось раньше и независимо от SPF/DKIM.

Понятно, что LLM это всё неведомо, так как LLM просто генерирует текст, а проверить его на соответствие реальности – просто некому. Дальше это всё попадает через “Хабр” в “поисковые системы”, которые, так как “Хабр” считается авторитетным, опять загоняют это всё в LLM и показывают пользователям, уже “со ссылками”. Поэтому-то результат и печалит.

В 2023 году я писал на dxdt.ru об одном из эффективных, для DNSSEC, способов динамического удостоверения факта отсутствия DNS-записи (или DNS-имени), который, в частности, применяют в Cloudflare. В конце 2025 года этот способ, с некоторыми добавлениями и обновлениями, получил спецификацию RFC 9824.

В частности, RFC 9824 вводит “мнимую” DNS-запись NXNAME (TYPE128) – это запись-сигнал об отсутствии в DNS-зоне запрошенного имени. Причина для введения такого сигнала в том, что упомянутый способ в принципе не позволяет отвечать со штатным для DNS статусом NXDOMAIN. Почему? Потому что весь смысл состоит в “подделывании” состава ответа, но, так сказать, с благими целями: при получении запроса о несуществующем имени, авторитативный сервер отвечает так, как если бы для этого имени нет DNS-записей в зоне: ANSWER: 0 и флаг NOERROR. В терминах DNS такой ответ называется NODATA – то есть, это корректный DNS-ответ без статуса ошибки, но пустой – не содержащий никаких ответных, – в блоке ANSWER, грубо говоря, – записей (естественно, это не означает, что DNS-ответ в целом не содержит записей: пуст только блок ANSWER, но записи в ответе есть, это дополнительные, “авторитативные” записи – SOA, NSEC и т.д.).

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

Для того, чтобы в новой схеме отличить ситуацию, когда действительно нет записей, от ситуации, когда нет имени, как раз и служит новая запись-сигнал NXNAME. Авторитативный сервер указывает NXNAME в составе полей NSEC-записи, если нет DNS-имени. NSEC – это запись, обозначающая “границу” зоны (в данном случае – фиктивную границу), NSEC нужна для того, чтобы было что подписывать, так как нельзя подписывать пустое значение. Технически, подписать-то можно, но такую подпись легко скопировать и применять к отсутствию любых записей в DNSSEC, то есть в безопасной DNS-зоне: это как раз пример того, что все пустые множества одинаковые, а окрашивать можно только пустые коробки, вот как в случае с NXNAME/NODATA и NXDOMAIN.

Здесь играет роль ещё одна нетривиальная особенность DNS, которую мало кто понимает. А именно: в DNS распространены ситуации, когда возникают заведомо пустые, но поименованные, фрагменты имени. Предположим, что есть имя a.b.c.example.com, для которого указана A-запись. Это имя находится в зоне example.com, но A-запись указана только для a.b.c. Как трактовать имя b.c.example.com (без a.)? Оно, вроде как, есть, потому что в DNS полное имя строится в форме иерархии лейблов, разделяемых точками. Но, не менее “вроде как”, этого имени и “нет”, потому что для него в принципе не указаны никакие записи: из “полных” имён тут будет только example.com и a.b.c.example.com. Для корректной обработки такого случая, в схеме, где NXDOMAIN-ответ невозможен, нужен сигнал, позволяющий отличить несуществование имени от несуществования записи для этого имени. Это и есть NXNAME.

Конечно, занимательно. Но, другое дело, что, с одной стороны, новый подход позволяет быстро, в онлайн-режиме генерировать подписанные DNS-ответы, удостоверяющие отсутствие запрошенной записи или отсутствие имени. С другой стороны, логика DNS очередной раз усложняется, а клиент, резолвер – должен подерживать обработку NXNAME, иначе для него разные пустые коробки склеиваются в одну (отсутствие записи склеивается с отсутствием имени).