В качестве непрофессионала я слежу за DNS примерно 18 доменов: в основном личные / личные домены для ближайших родственников. Весь shebang передан на аутсорсинг недорогому провайдеру управляемого хостинга, у которого есть веб-интерфейс, через который я управляю зонами.
Эти домены настолько неважны, что атака, нацеленная на них, кажется гораздо менее вероятной, чем общий взлом систем моего провайдера, после чего записи всех их клиентов могут быть изменены на неправильное перенаправление трафика (возможно, с очень длинным TTL). DNSSEC может смягчить такую атаку, но только если закрытые ключи зон не принадлежат хостинг-провайдеру.
Итак, мне интересно: как можно держать закрытые ключи DNSSEC в автономном режиме, но при этом передавать подписанные зоны на внешний DNS-хост?
Самый очевидный ответ (по крайней мере, для меня) - запустить собственный теневой / скрытый мастер (от которого провайдер может подчиняться), а затем скопировать подписанные офлайн файлы зоны на мастер по мере необходимости.
Проблема в том, что единственная машина, которую я (хочу*) control - это мой личный ноутбук, который обычно подключается через обычный домашний ADSL (то есть за NAT по динамически назначаемому IP-адресу). Их рабство от этого (например, с очень длинным Expiry время в зоне в течение периодов, когда мой ноутбук отключен / недоступен) не только потребует динамической записи DNS, из которой они могут подчиняться (если они действительно могут подчиняться с именованного хоста, а не с явным IP-адресом), но также будет включать меня запуск DNS-сервера на моем ноутбуке и открытие его и моей домашней сети для входящих запросов передачи зоны: не идеально.
я буду предпочитаю гораздо более ориентированный на push дизайн, при котором мой ноутбук инициирует передачу офлайн-подписанных файлов зоны / обновлений провайдеру.
Я смотрел, есть ли nsupdate может соответствовать всем требованиям: документация немного отрывочна, но мое тестирование (с BIND 9.7) показывает, что она действительно может обновлять зоны DNSSEC, но только там, где сервер хранит ключи для выполнения подписи зоны; Я не нашел способа получить обновление, включая соответствующий RRSIG / NSEC / etc. записи и пусть сервер их примет. Это поддерживаемый вариант использования?
Если нет, то я подозреваю, что единственные решения, которые могут соответствовать всем требованиям, будут включать передачу обновлений зоны без использования DNS и будут приветствовать рекомендации, которые поддерживаются (надеюсь, недорогими) хостинг-провайдерами: SFTP / SCP? rsync? Репликация СУБД? Собственный API?
Наконец, каковы будут практические последствия такой установки? Смена клавиш кажется мне очевидной трудностью, особенно если мой ноутбук отключен в течение длительного времени. Но зоны чрезвычайно стабильны, поэтому, возможно, мне удастся обойтись долгоживущими ZSK.**...?
* Хотя я мог запустить мастер теней / скрытых, например, VPS, переданный на аутсорсинг, мне не нравятся накладные расходы, связанные с безопасностью / управлением / мониторингом / обслуживанием еще одной системы; не говоря уже о дополнительных финансовых затратах на это.
** Хорошо, это позволит решительному злоумышленнику воспроизвести записи с истекшим сроком действия, но в случае этих доменов и риск, и влияние такого рода допустимы.
Ваша проблема не столько в ротации ключей, сколько в RRSIG истечение срока.
Срок службы ключей обычно измеряется в диапазоне от 6 месяцев до 3 лет, и растет число мыслителей, которые говорят, что вам вообще не следует катать ключи.
Однако, чтобы избежать атак повторного воспроизведения, вам необходимо регулярно заново подписывать все свои записи, а RRSIG срок действия обычно составляет от 1 до 2 недель.
Если вы подписали зону самостоятельно и передали ее на хост, вам нужно будет делать это перед каждым событием истечения срока действия RRSIG, в то же время принимая во внимание истечение срока действия TTL и т. Д. (См. черновик-ietf-dnsop-dnssec-ключ-время и RFC 4641).
Если ваш DNS-провайдер все делает правильно, у него должен быть (очень) долговечный Ключ для подписи которые должны храниться в аппаратном модуле безопасности и подключаться к сети только при необходимости, что должно быть эффективно непроницаемым.
Только Ключ подписи зоны затем необходимо сохранить в сети.