Мне было поручено изучить возможность внедрения DNSSEC на наших серверах имен. Хотя техническая сторона этого (создание ключей, подписание зон, подготовка ролловеров) относительно проста, я столкнулся с логистической проблемой.
Из документации, которую я читал, 1024 бита - хороший размер для ключа подписи зоны, и правильной процедурой будет один ZSK для каждой зоны с примерно месячным переносом.
Однако на достаточно быстром компьютере с приличной энтропией для генерации 1024-битного ключа требуется до 10 минут ... И провайдер, которого я работаю, для хостов с более чем тремя тысячами зон. Если я каким-то образом не автоматизирую процесс от начала до конца, это не будет работать - и даже если я это сделаю, к тому времени, когда процесс завершится, почти пора будет начать с СЛЕДУЮЩЕГО ролловера.
Короче говоря, это невозможно. Прямо сейчас я ограничиваю DNSSEC для клиентов, которые явно просят об этом, но в лучшем случае это временная мера.
Мои вопросы:
РЕДАКТИРОВАТЬ: добавлены точные команды, которые я использую для генерации ключей:
caleburn: ~/Projects/Systemec/DNS-magic/DNSSEC/keys/ >time dnssec-keygen -r/dev/random -a RSASHA256 -f KSK -b 1280 -n ZONE example.com
Generating key pair.............................+++++ ...+++++
Kexample.com.+008+10282
real 9m46.094s
user 0m0.092s
sys 0m0.140s
caleburn: ~/Projects/Systemec/DNS-magic/DNSSEC/keys/ >time dnssec-keygen -r/dev/random -a RSASHA256 -b 1280 -n ZONE example.com
Generating key pair.........................+++++ .........+++++
Kexample.com.+008+22173
real 12m47.739s
user 0m0.124s
sys 0m0.076s
dnssec-keygen читает из /dev/random по умолчанию. Если энтропия в вашей системе низкая, вы не получите достаточно случайных данных для своевременной генерации ключей. strace, вероятно, покажет много чего:
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3, "5%\5\32\316\337\241\323", 46) = 8
read(3, 0x7fff5b6c3df0, 38) = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3, "\305\35\201c\31\343\251\21", 38) = 8
read(3, 0x7fff5b6c3df0, 30) = -1 EAGAIN (Resource temporarily unavailable)
/dev/random блоки, если энтропии недостаточно, поэтому это может занять некоторое время.
У вас есть несколько способов сделать это намного быстрее. Самый простой - использовать сдачу -r /dev/random к -r /dev/urandom использовать неблокирующий (но не такой безопасный) генератор случайных чисел. Это может считаться небезопасным для чего-то вроде ключа GPG или SSH, который вы ожидаете использовать в течение нескольких лет, но, вероятно, безопасно для чего-то, что вы будете менять каждые 30 дней.
Другой вариант - использовать что-то вроде EGD или кованый в качестве замены /dev/random.
Если вам нужен гораздо более безопасный ГСЧ, вам лучше использовать специальный аппаратный ГСЧ. Это, вероятно, излишек для DNSSEC, если вы не управляете доменами верхнего уровня или банковскими доменами.
Вы можете использовать / dev / random для KSK, но / dev / urandom подойдет для ZSK.
Я думаю, что общее мнение заключается в том, что ваш ZSK должен быть 1024-битным и обновляться каждый квартал, а ваш KSK должен быть 2048-битным и обновляться каждые пару лет.