11 октября 2026 года корневая зона DNS начала подписываться только новым ключом KSK-2024 с идентификатором 38696. Для большинства рабочих систем это событие проходит незаметно: резолверы, которые уже содержат новый ключ в якорях доверия, продолжают работать. Проблема проявляется в другом сценарии — когда вы пересоздаёте контейнер или разворачиваете резолвер с пустым состоянием, а в образе или конфигурации остался только старый ключ. В этом случае DNS может перестать отвечать на любые запросы, включая неподписанные домены вроде google.com. Разберём, почему так происходит, как диагностировать причину и что делать, чтобы не потерять часы на отладку.

Что именно меняется и почему это важно для контейнеров

Корень DNS подписывается набором ключей. До смены в якорях доверия резолверов обычно присутствовали два ключа: старый и новый. После 11 октября 2026 года корень подписывает набор только новым KSK-2024 (38696). Если резолвер при первом запуске не имеет актуального якоря и не может его получить, он не сможет проверить подпись корневой зоны. В результате любой запрос, требующий валидации DNSSEC, завершается ошибкой SERVFAIL. Причём это касается и неподписанных доменов: резолверу всё равно нужно проверить цепочку доверия от корня, чтобы убедиться в отсутствии подписи.

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

Как ведут себя разные резолверы при пустом состоянии

Поведение зависит от реализации и дистрибутива. Вот что важно знать:

  • BIND из Debian 11 с одним старым ключом. При первом запуске он может сам начать доверять новому ключу, если у него есть доступ к корневым серверам и механизм RFC 5011 включён. Однако это не гарантировано: если доступ к сети ограничен или первый запрос приходит до завершения обновления, вы получите SERVFAIL. В экспериментах с пустым состоянием через 20 дней после смены BIND отдавал SERVFAIL на всё, включая google.com.
  • unbound. Для старта с пустым состоянием предусмотрен unbound-anchor. Он пытается получить актуальный якорь по HTTPS с data.iana.org. Если HTTPS доступен, проблема решается. Если нет, утилита записывает старый ключ и завершается с кодом 0, что может ввести в заблуждение: формально успех, но якорь неверный. В контейнере без внешнего HTTPS это приведёт к SERVFAIL.
  • dnsmasq из Debian 12. Со своим файлом якорей он отказывает на всех запросах. Если в якорях присутствует 38696, dnsmasq работает. В Debian 12 актуальные якоря подставляет сервисная обёртка дистрибутива, поэтому важно не перезаписывать файл якорей вручную устаревшей версией.

Общая закономерность: если в якорях доверия нет ключа 38696 и нет возможности его получить, резолвер не сможет валидировать ответы. Ошибка проявляется как SERVFAIL на любой запрос, а не только на подписанные зоны.

Как диагностировать проблему и не спутать с сетевой

Первое, что стоит сделать при SERVFAIL в контейнере, — проверить, не является ли это следствием смены ключа. Вот последовательность шагов:

  • Проверьте, какие якоря доверия использует ваш резолвер. Для BIND это файл managed-keys.bind или bind.keys; для unbound — root.key; для dnsmasq — файл, указанный в trust-anchor. Убедитесь, что в нём присутствует ключ с ID 38696.
  • Попробуйте выполнить запрос к неподписанному домену, например dig google.com. Если ответ SERVFAIL, а прямой запрос к корневому серверу по IP работает, проблема скорее в валидации, а не в сетевой доступности.
  • Проверьте, может ли контейнер получить актуальный якорь. Для unbound запустите unbound-anchor -v и посмотрите, пытается ли он обратиться к data.iana.org. Если HTTPS недоступен, утилита может записать старый ключ и завершиться успешно — это ловушка.
  • Сравните поведение с хостом, где резолвер работал непрерывно. Если там запросы проходят, а в контейнере нет, вероятна именно проблема с якорями.

Типичная ошибка — сразу искать проблему в firewall или в DNS-серверах провайдера. Если dig @8.8.8.8 google.com работает, а локальный резолвер отдаёт SERVFAIL, сетевая доступность ни при чём.

Что делать: практические шаги для BIND, unbound и dnsmasq

Действия зависят от того, какой резолвер вы используете и есть ли у вас контроль над образом.

  • Обновите якоря доверия в образе. Для BIND добавьте в bind.keys или в конфигурацию trust-anchors новый ключ 38696. Для unbound обновите root.key с помощью unbound-anchor на машине с доступом к HTTPS и скопируйте файл в образ. Для dnsmasq используйте файл якорей, поставляемый дистрибутивом, и не перезаписывайте его устаревшей версией.
  • Обеспечьте доступ к data.iana.org при старте. Если вы полагаетесь на автоматическое обновление, убедитесь, что контейнер может ходить по HTTPS на data.iana.org. В закрытых средах это не всегда возможно, поэтому лучше иметь актуальный якорь в образе.
  • Не игнорируйте код возврата unbound-anchor. Код 0 не гарантирует, что якорь обновлён. Проверяйте содержимое файла после запуска.
  • Для BIND с RFC 5011. Если вы рассчитываете на автоматическое обновление, дайте резолверу время и доступ к корневым серверам до первых пользовательских запросов. В контейнере это сложно, поэтому надёжнее явно указать новый ключ.
  • Проверьте, не переопределяете ли вы файл якорей. В Debian 12 dnsmasq полагается на сервисную обёртку, которая подставляет актуальные якоря. Если вы монтируете свой файл, убедитесь, что в нём есть 38696.

После изменений пересоздайте контейнер и проверьте запросы к подписанным и неподписанным доменам. Убедитесь, что SERVFAIL исчез.

Пример из практики и типичные ошибки

Представьте: вы обновляете приложение, пересоздаёте контейнер с BIND из Debian 11, и вдруг все сервисы внутри теряют DNS. Логи показывают SERVFAIL. Вы проверяете сеть — всё в порядке. Начинаете копать в сторону DNSSEC и обнаруживаете, что в образе остался только старый ключ. Через 20 дней после смены BIND с пустым состоянием уже не может автоматически перейти на новый ключ без доступа к корневым серверам. Решение — добавить 38696 в якоря или обновить образ.

Другая распространённая ошибка — слепо полагаться на unbound-anchor в изолированном контейнере. Утилита может записать старый ключ и выйти с кодом 0, а вы будете думать, что всё хорошо. Всегда проверяйте содержимое файла якорей после запуска.

Ещё одна ошибка — перезаписывать файл якорей dnsmasq вручную, не проверяя, есть ли в нём 38696. В Debian 12 дистрибутив уже поставляет актуальные якоря через сервисную обёртку, и вмешательство может всё сломать.

Наконец, не стоит недооценивать проблему: смена ключа произошла 11 октября 2026 года, и если ваш образ собран раньше, он почти наверняка содержит устаревшие якоря. Проверьте свои Dockerfile и конфигурации заранее, чтобы пересоздание контейнера не привело к внезапному отказу DNS.