Кратко

  • RFC 9824 допускает ответ для несуществующего имени с NOERROR в заголовке, пустым разделом ответа и подписанным NSEC/NSEC3 с NXNAME. Аутентифицированное утверждение находится в теле; DNS-заголовок криптографически не защищён.
  • Необязательный флаг EDNS Compact Answers OK позволяет восстановить NXDOMAIN, но действует между соседями. Резолвер обязан хранить эту способность вместе с доказательством в кэше и менять представление для следующего клиента.
  • Компактные ответы сокращают доказательство и работу подписи относительно других онлайновых форм, но исключают агрессивный отрицательный синтез. Проверка, представление, кэш, нагрузка и эффект приложения требуют разных квитанций.

У выгоды была одна строка, у перенесённой стоимости — ни одной

Вступление описывает условное решение, а не реальное внедрение. Его ошибка в границе расчёта: сравнивается одна операция на авторитетном сервере, но не изменение поведения резолвера, инструментов и приложений.

RFC 9824 определяет компактное доказательство отсутствия в DNSSEC. Обычное отрицательное доказательство показывает отсутствие точного имени и невозможность синтеза по шаблонной записи. При онлайн-подписи для этого может понадобиться до двух подписанных NSEC или трёх NSEC3.

Компактный ответ меняет логическую форму. Для отсутствующего имени без подходящей шаблонной записи авторитетный сервер создаёт ответ, похожий на NODATA: RCODE NOERROR, пустой раздел ответа и один подписанный минимально покрывающий NSEC/NSEC3, совпадающий с QNAME. В доказательстве имя объявляется существующим, но не имеющим запрошенного типа.

Страница RFC Editor и Datatracker указывают статус Proposed Standard и публикацию в сентябре 2025 года; документ обновляет RFC 4034 и 4035. История, список ссылок и обратные ссылки описывают публичный контекст, но не подтверждают реализацию или эксплуатацию.

NXNAME превращает пустоту в подписанное утверждение

Пустой раздел ответа неоднозначен. Имя может существовать без нужного типа. Пустое нетерминальное имя существует благодаря потомкам, хотя не имеет собственных RRset. Разреженная карта типов не разделяет эти случаи.

RFC 9824 вводит синтетический Meta-TYPE NXNAME со значением 128. В NSEC-ответе для отсутствующего имени карта типов содержит RRSIG, NSEC и NXNAME. В NSEC3 NXNAME — единственная запись. У пустого нетерминального имени её нет. Вывод основан не на молчании, а на подписанном материале.

IANA DNS Parameters регистрирует NXNAME, флаг CO и EDE 30. Регистрация согласует идентификаторы, но не доказывает включение, проверку или результат.

NXNAME не является обычными данными зоны и не предназначен для запроса. Он появляется лишь в карте типов NSEC/NSEC3 компактного ответа. Явный QTYPE NXNAME получает FORMERR, при желании с EDE 30 Invalid Query Type. Резолвер не пересылает его вверх и не начинает итеративное разрешение. RFC 8914 задаёт общий механизм EDE.

Заголовок показывает, подписанное тело доказывает

RFC 9824 подчёркивает: DNS-заголовок криптографически не защищён, поэтому RCODE нельзя аутентифицировать. Подписанные данные тела дают более сильное основание для вывода о несуществовании.

RCODE остаётся важным интерфейсом библиотек и средств безопасности. Инструмент видит NOERROR и сообщает NODATA. Валидатор проверяет RRSIG и NXNAME и сообщает отсутствие имени. Обе записи сохраняются с точкой наблюдения; удобное поле не отменяет более сильного свидетеля.

RFC 4034 определяет NSEC, RRSIG и другие DNSSEC RR. RFC 4035 задаёт обработку и аутентифицированное отрицание. RFC 9824 добавляет исключение для динамической компактной формы. RFC 9364 даёт обзор DNSSEC, RFC 9499 — терминологию. Ни один текст не превращает непроверенный заголовок в подписанный факт.

Минимальная квитанция связывает имя и тип запроса, DO/CO, полученный RCODE, форму NSEC/NSEC3, NXNAME, публичные идентификаторы алгоритма и ключа, результат проверки, версию ПО, время и отпечаток доказательства. Закрытый ключ в неё не попадает.

CO меняет представление между соседями

RFC 9824 рекомендует сохранять NXDOMAIN, когда возможно, и определяет EDNS Compact Answers OK. Резолвер с CO заявляет, что примет подписанный NXNAME вместе с восстановленным RCODE NXDOMAIN. Авторитетный сервер с обеими возможностями может вернуть CO и этот код.

EDNS по RFC 6891 действует между соседними узлами. Резолвер хранит полученный CO вместе с данными кэша. Если следующий DNSSEC-клиент не послал CO, RCODE NXNAME-ответа возвращается к NOERROR.

Подписанное доказательство одинаково, локальное представление различается. Потеря CO при сохранении или репликации кэша лишает решение основания. Последний RCODE не показывает, была ли проверка, адаптация или простая ретрансляция.

Компактность перераспределяет работу

RFC 4470 описывает минимально покрывающий NSEC и онлайн-подпись; RFC 5155 — NSEC3. RFC 9824 сокращает размер и операции подписи относительно более крупных динамических доказательств и препятствует полезному перечислению зоны.

Однако компактные ответы не допускают синтез NXDOMAIN и шаблонных ответов из RFC 8020 и RFC 8198. Псевдослучайные поддоменные запросы чаще доходят до авторитетного сервера вместо ответа из агрессивного отрицательного кэша.

Онлайн-подпись держит закрытую подписывающую способность на доступной из Интернета инфраструктуре и вычисляет доказательство по запросу. Компактный ответ уменьшает относительную работу, но не становится заранее вычисленной подписью. RFC 9824 признаёт вычислительную подверженность DoS и оставляет другие методы доступными.

Результат приложения — отдельное наблюдение

Библиотека адресов после NODATA для AAAA может запросить A того же имени; NXDOMAIN мог бы подавить второй запрос. Заглушечный резолвер может не просить DNSSEC, средство защиты — не читать карту типов, рекурсивный резолвер — изменить RCODE для клиента без CO.

Running-Code Primacy требует идти по выполненной цепочке: генерация, подпись, проверка, интерпретация NXNAME, кэш, решение CO, выданный RCODE, дополнительный запрос и результат приложения. Reality Layers не позволяют NOERROR отвергнуть подписанное доказательство и не позволяют валидной подписи стать доказательством успеха приложения.

Источники

  1. IETF Datatracker: RFC 9824
  2. История RFC 9824
  3. Документы, ссылающиеся на RFC 9824
  4. Ссылки RFC 9824
  5. Heng Lu: Minimum Initial Specification
  6. Heng Lu: Reality Layers
  7. Heng Lu: Running-Code Primacy
  8. IANA DNS Parameters
  9. Errata RFC 9824
  10. Информация RFC Editor
  11. RFC 4034
  12. RFC 4035
  13. RFC 4470
  14. RFC 5155
  15. RFC 6891
  16. RFC 8020
  17. RFC 8198
  18. RFC 8914
  19. RFC 9364
  20. RFC 9499
  21. RFC 9824