Кратко

  • RFC 9953 рекомендует ставить ID заголовка DNS в 0, чтобы эквивалентные DoC-запросы использовали один вход CoAP Cache-Key.
  • Повторное использование ограничено совместной арифметикой Max-Age и TTL DNS и не доказывает само по себе ответ DNS, источник, валидацию, локальную политику или совершённое действие.

Устройство просыпается на узкой сети и спрашивает один DNS-имя. Промежуточный CoAP-кэш может вернуть уже имеющееся представление. Это снижает число передач и расход энергии — именно такую пользу предполагает DNS over CoAP. Однако наблюдение «ответ пришёл из кэша» не говорит, каким был источник выше по цепочке, сколько времени осталось записи, проверялась ли она, разрешила ли её локальная политика и что сделало приложение после получения байтов.

RFC 9953, опубликованный в марте 2026 года, определяет DNS over CoAP (DoC) для DNS-запросов OPCODE 0. Пара DNS-запроса и DNS-ответа отображается на одну операцию CoAP request-response. Запрос находится в теле CoAP FETCH; DNS-сообщение передаётся как application/dns-message, Content-Format 553. Такой перенос использует возможности CoAP в ограниченном IoT-сценарии. Он не превращает внешний транспортный результат в решение о достоверности всего DNS-содержимого.

Нулевой ID имеет только кэшевое назначение. Клиент DoC SHOULD установить поле ID заголовка DNS в 0, чтобы запросы тех же DNS-данных не получали разные CoAP Cache-Key лишь из-за обычного идентификатора транзакции. Тогда кэш или прокси в пути может повторно отдать представление. Сервер DoC MUST скопировать ID запроса в ответ. Ноль не является именем сервера, признаком доверия или разрешением для автоматики; он убирает случайное различие из ключа кэша.

За этим следует обязательная дисциплина времени. Сервер DoC MUST обеспечить, чтобы сумма CoAP Max-Age и каждого TTL DNS в ответе была не больше соответствующего TTL, полученного от вышестоящего DNS-сервера. Если опция отсутствует, в расчёт входит и стандартный CoAP Max-Age в 60 секунд. Получив ответ, клиент DoC MUST прибавить Max-Age к каждому TTL DNS и применять вычисленные TTL. Время жизни в кэше транспорта и время жизни в DNS-теле — части одного лимита, а не два самостоятельных разрешения.

Рекомендуемый алгоритм устанавливает Max-Age равным минимальному TTL DNS и вычитает это значение из всех TTL в DNS-ответе. Так промежуточный кэш не должен нечаянно отдать истёкшую запись, а ETag, основанный на содержимом, может не меняться при обновлении остаточного TTL в вышестоящем кэше. Для ошибки, которую разумно хранить лишь недолго, Max-Age может быть меньше или равен нулю. Правило управляет истечением срока; оно не объявляет кэшированный ответ равным текущему состоянию мира.

Нужно сохранить два разных статуса. Разбираемый DNS-ответ рекомендуется передавать как CoAP 2.05 Content, даже когда DNS внутри сообщает NXDOMAIN либо другой ошибочный RCODE. Неуспешные коды CoAP предназначены для ошибки слоя CoAP или запроса, не соответствующего DoC. Метрика, которая считает любой 2.05 успехом DNS, скрывает ошибку DNS. Метрика, которая читает только RCODE, скрывает различие между ошибкой DNS выше по цепочке и транспортной ошибкой.

Роль DoC-сервера также не вытекает из кэша. Сервер может быть авторитативным, stub или рекурсивным и MAY быть валидатором DNSSEC для ограниченного клиента. (D)TLS и OSCORE могут защищать обмен. Это не означает, что каждый ответ прошёл DNSSEC-валидацию, удовлетворяет локальной политике или привёл к корректному эффекту приложения. Daniel Kade использует подход Heng Lu к работающему коду только как редакционную линзу: кэшируемость, источник, проверка, время и эффект принадлежат разным слоям доказательств.

Источники