DNSSEC на внешней зоне клиента: ключи ротировали, нервы потрепали

В июле ICANN подписала корневую зону DNS ключами DNSSEC. Событие технически значимое: цепочка доверия теперь начинается от корня, и подписывать свои зоны стало не просто теоретическим упражнением, а чем-то, что имеет смысл на практике. Регистраторы потихоньку добавляют поддержку DS-записей в панели управления. Один из клиентов спросил: «А нам это надо?» Мы подумали и ответили: «Попробуем - узнаем».

Что и зачем

Клиент - небольшая компания с одним внешним доменом, несколькими MX-записями и корпоративным сайтом. Инфраструктура простая, регистратор поддерживает DS-записи через API, внешний DNS работает на паре BIND 9.7 на VDS. Казалось бы, всё складывается.

DNSSEC здесь решает конкретную проблему: атаки на отравление DNS-кеша (cache poisoning), о которых шум поднялся после бага Каминского в 2008-м. Подписанная зона позволяет резолверу проверить, что ответ не подделан по дороге. Для внешнего домена компании, где лежат MX-записи, это не паранойя - это разумная мера.

Как настраивали

Схема стандартная для BIND с inline signing:

• ZSK (Zone Signing Key) - 1024-битный RSA, им подписываются сами записи зоны. Меняется чаще.
• KSK (Key Signing Key) - 2048-битный RSA, им подписывается DNSKEY-запись. Меняется реже, именно его хеш идёт как DS-запись к регистратору.

Генерация ключей через dnssec-keygen, файлы в отдельную директорию, в named.conf добавили dnssec-enable yes; dnssec-validation yes; и прописали ключи в зону. BIND подписывает зону автоматически при загрузке, генерирует RRSIG-подписи со сроком действия. Плюс добавили NS_KEYS в зону и отправили DS-запись регистратору.

Проверка через dig с флагом +dnssec и онлайн-инструментами типа dnsviz показала корректную цепочку. Всё зелёное, всё работает. Мы немного порадовались.

Где всё пошло не так

Примерно через две недели появилась первая неприятность: RRSIG-подписи у ZSK протухли. BIND должен был их автоматически обновлять, но из-за особенностей конфигурации sig-validity-interval делал это слишком поздно - за двое суток до истечения, и в один прекрасный момент сервер просто не успел переподписать зону вовремя из-за нагрузки. Резолверы с включённой DNSSEC-валидацией начали возвращать SERVFAIL.

Обнаружили через мониторинг не сразу - Nagios проверял доступность сайта с резолвером без DNSSEC-валидации, поэтому снаружи «всё работало», пока один из сотрудников клиента не пожаловался, что с домашнего роутера сайт не открывается. Роутер оказался с включённой DNSSEC-валидацией.

Исправили быстро - принудительно переподписали зону, скорректировали sig-validity-interval до недели с автообновлением за трое суток. Но осадок остался.

Второй эпизод был интереснее. Мы запланировали ротацию ZSK - процедуру, которую рекомендуется проводить регулярно. На бумаге всё выглядело разумно:

1. Добавить новый ZSK в зону, дождаться распространения (TTL зоны - час).
2. Начать подписывать новым ключом, держа старый в зоне ещё один TTL.
3. Убрать старый ZSK.

На практике мы не учли, что резолверы, закешировавшие старые RRSIG-подписи, держат их ровно до истечения срока RRSIG, а не TTL зоны. Убрали старый ZSK чуть раньше, чем надо. Снова SERVFAIL у части пользователей, снова несколько неприятных часов.

Что задокументировали

После второго инцидента сели и написали конкретную процедуру ротации ZSK с временными интервалами и чеклистом:

• Перед ротацией - убедиться, что мониторинг проверяет зону именно с резолвером, у которого включена DNSSEC-валидация. Иначе вы узнаете о проблеме от пользователей, а не от системы.
• Интервал выдержки после добавления нового ключа - не меньше максимального TTL подписей (у нас было 3 суток), а не просто TTL зоны.
• Ротация KSK требует отдельного шага с обновлением DS-записи у регистратора и ожиданием её распространения - это дни, не часы. Это не тот процесс, который можно делать в пятницу вечером.
• Логировать всё - когда именно были добавлены ключи, когда убраны, какие были RRSIG-сроки на момент ротации.

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

Итог

DNSSEC работает и цепочка доверия держится. Два инцидента с SERVFAIL были неприятны, но оба разрешились за несколько часов без потери данных и без серьёзных последствий для бизнеса клиента.

Главный вывод: DNSSEC проще включить, чем сопровождать. Подписать зону - дело двух часов. Ротация ключей, мониторинг подписей, правильные интервалы - это операционная нагрузка, которая не бросается в глаза при первоначальной настройке. Документируйте процедуры сразу, пока ещё помните, почему сделали именно так.

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