Архивы рубрики ‘Без рубрики’

Беспонтовый lvm cache

/dev/sda — основной винт
/dev/sdb — ssd
data — lvgroup
DataLV — lv

# pvcreate /dev/sdb
# vgextend data /dev/sdb

Два раздела под данные и под метаданные. Под данные в 1000 раз больше места надо чем под меты.

# lvcreate -n DataLVcache -L19.9G data /dev/sdb
# lvcreate -n DataLVcacheMeta -L20M data /dev/sdb

# lvconvert —type cache-pool —cachemode writethrough —poolmetadata data/DataLVcacheMeta data/DataLVcache

writeback VS writethrough — неясно. Типа writethrough более надёжный, а writeback более быстрый. На чтение вообще никак не влияет.

# lvconvert —type cache —cachepool data/DataLVcache data/DataLV

Типа готово.

Режим кэширования меняется так:
# lvconvert —cachemode writethrough|writeback VG/CacheLV

Плюс нашёл только один — всё меняется на лету. Без перемонтирования и перезагрузок. Данные не страдают.

Огромный минус — не смог загрузиться с кэшированной rootfs. Предлагают только танцы с бубном с пересборкой ядра. А это не наш метод.

Ненавистный audit в Fedora

Боремся:
You can quickly disable audit temporarily with

$ sudo auditctl -e 0

and temporarily remove all the rules with

$ sudo auditctl -D

For future boots you could try disabling its start with

$ sudo systemctl disable auditd

До кучи:
# systemctl disable systemd-journald-audit.socket
# systemctl stop systemd-journald-audit.socket

Mustek 1248UB and Fedora 20

Напомню себе, что в Fedora недостаточно поставить sane и xsane со всеми зависимостями, чтобы Mustek 1248UB заработал. Закачать прошивку с оффсайта http://www.meier-geinitz.de/sane/gt68xx-backend/index_ru.html тоже не поможет. Еще нужен sane-backends-drivers-scanners
Это логично, но не очевидно. 😉

Внезапно: Простоквашино

Уже неделю смотрю с сыном мультики про троих из Простоквашино. Сейчас они воспринимаются по-другому. Матроскин и Шарик постоянно ругаются и спорят, а мамаша Дяди Фёдора вообще злобная истеричка.
Самый добрый из последнего вновь увиденного — «Жил был пёс»

Proxmox и IPv6

Время заставляет использовать IPv6. Работать IPv6 под Proxmox удалось настроить только в режиме моста.
Хост под Proxmox настраиваем как обычно:
/etc/network/interfaces:

iface vmbr0 inet6 static
        address 2a00:15f8:C001:3::2
        netmask 64
        gateway 2a00:15f8:c001:3::22

Переподнимаем интерфейс или перезапускаем сеть.

Далее останавливаем контейнер. Добавляем в контейнер «Сетевое оборудование» (например, ipv6). Правим в контейнере файл /etc/network/interfaces.tail:

auto ipv6
iface ipv6 inet6 static
	address 2a00:15f8:C001:3::3
	netmask 64
	gateway 2a00:15f8:c001:3::22
	up route -A inet6 del default dev venet0

Последняя строчка нужна чтобы уничтожить вражеский маршрут добавляемый в /etc/network/interfaces (вот зачем они так сделали?):

iface venet0 inet6 manual
	up route -A inet6 add default dev venet0
	down route -A inet6 del default dev venet0

Запускаем контейнер.

После этого делаем ping6 ipv6.google.com и радуемся.

Upgrade Fedora 17 до 18 x86_64

Прошел на редкость удачно по несложному сценарию:

#!/bin/bash -x

rpm --import https://fedoraproject.org/static/DE7F38BD.txt

yum update yum
yum clean all
yum --releasever=18 --disableplugin=presto upgrade "yum*" "rpm*"
yum --releasever=18 --disableplugin=presto distro-sync --skip-broken
yum --releasever=18 --disableplugin=presto distro-sync

rpm --rebuilddb

После чего перестал работать skype:
$ skype
skype: error while loading shared libraries: libQtGui.so.4: cannot open shared object file: No such file or directory

Вылечилось:
yum install qt-x11-4.8.5-6.fc18.1.i686

Любопытное наблюдение…

…как только закрыл iptables’ом 53 tcp порт на всех DNS серверах для всех кроме своих же серверов количество всякого бредового tcp флуда (в т.ч. http) стало почти нулевым…

Небольшое хранилище для небольших файлов

В процессе разработки одного проекта появилось требование хранить множество файлов (более 4 млн. штук). И в процессе количество файлов постоянно росло. Когда из количество перевалило через 6 млн. появилась проблема с работой с этими файлами. Даже разложив их по каталогам и создав разветвлённое дерево обход даже части этих каталогов стал занимать часы. Разумеется вначале никто не задумался над тем как это будут хранить и использовали обычный винт и ext4. В какой-то момент скорость чтения с этого раздела достигла 9MB/sec. Это слишком медленно. Экспериментальный переход на btrfs поднял в результате эту скорость до 13MB… Хотя это тоже не впечатляет. ssd для этого никто не собирался использовать да и объём уже перевалил через 1TB. Т.е. всё шло к использованию райдов. Поскольку коммерческий успех проекта остаётся под сомнением, то стоимость должна быть минимальной. А значит реализация должна быть программной.

Итак, нужно небольшое хранилище — на одном сервере/компьютере, т.е. до 4х дисков. Хранить нужно небольшие файлы — 1-3Mb каждый.
btrfs в нашем случае уже оказалась быстрее ext4, поэтому она и будет использоваться.
Кандидатами на управление хранилищем стали raid0 и raid10. Raid0 очевидно и объективно самый быстрый. Нередко утверждение, что самый быстрый raid10. Если подумать, то raid10 теоретически может быть таким же быстрым как и raid0 при чтении. Но вот для записи — очень сомнительно. Да и без особого труда можно найти различные тесты производительности аппаратных raid’ов.
Очевидное преимущество raid10 — надежность — не так уж и очевидно для не очень важных данных. Тем не менее, если надо хранить много, то используют либо raid, либо lvm. Можно и по старинке — вручную разделить данные по винтам. Надёжность везде одинаковая. Теряем винчестер — теряем данные. В raid0 размер strip’а (chunk) настраивается, поэтому при небольшом размере файлов большую часть данных можно будет таки восстановить.

В качестве подобытных были взяты 4 hdd Western Digital Caviar Blue 1TB
Пожалуй, один из самых быстрых среди имеющихся в свободном доступе без завышения цены.

raid0 собираем совершенно штатным образом:

mdadm -v —create /dev/md0 —level=raid0 —raid-devices=4 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Создание происходит мгновенно, ибо копировать и переразмечать нечего.
Сохраняем конфиг, чтоб при перезагрузке массив остался:

mdadm —examine —scan —config=mdadm.conf >> /etc/mdadm.conf

Создаём файловую систему:

#mkfs.btrfs -Lraid0 /dev/md0

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label raid0 on /dev/md0
        nodesize 4096 leafsize 4096 sectorsize 4096 size 3.64TB
Btrfs Btrfs v0.19

Интересно то, что FS всё еще экспериментальная. Впрочем это нисколько не помешало разработчикам Fedora 18 сделать btrfs файловой системой по умолчанию.

Проведём быстрый тест на скорость:

# hdparm -t /dev/md0

/dev/md0:
 Timing buffered disk reads: 2008 MB in  3.00 seconds = 669.11 MB/sec

В общем-то скорость линейного чтения колеблется от 650 до 690MB/sec.
Это, для сравнения, быстрее чем любой sata3 ssd ибо скорость больше чем способна пропустить sata3.
Полезный объём устройства 3,7T
Двух дневный тест показал устойчивую скорость и произвольного чтения и произвольной записи в 202MB/sec и 220MB/sec при операциях с файлами. Если ограничиться только чтением или только записью, то получаем 560MB/sec. Это устойчивые средние значения.
Весьма неплохо. Кстати, многие домашние ssd до этого не дотягивают.
Скорость весьма приличная на текущий момент. Поэтому собственно на нём и остановились. В случае, если один из винтов начнёт сыпаться, то придётся остановить весь raid, скопировать посекторно данные на новый винт и вернуть raid в активное состояние. Вполне допустимо для не очень важного хранилища. Если оно внезапно станет важным, то можно будет повысить его надежность и общую отказоустойчивость при помощи drbd.
В процессе тестирования нередко наблюдались пиковые скорости чтения и записи в 700MB/sec. Но поскольку файлы у нас маленькие, то такие пики возникали при параллельном чтении множества файлов. Видимо сказывается размер chunk’а.

Для очистки совести проведём те же тесты с raid10.
Создание raid10:

mdadm -v —create /dev/md0 —level=raid10 —raid-devices=4 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Но тут придётся подождать какое-то время. Пару-тройку часов.
В результате имеем следующее:

# hdparm -t /dev/md0

/dev/md0:
Timing buffered disk reads: 1080 MB in 3.01 seconds = 359.07 MB/sec

Мягко говоря разочаровывает. Точно такие же результаты были на raid0 с двумя дисками. Теоретическая возможность чтения с 4х винтов в данном случае не проявляется.
Но линейная скорость хоть и показательна, но не так важна для нас. Важнее произвольный доступ к файлам.
И он составил 190MB/sec на чтение и 125MB/sec на запись.
Полное разочарование с записью. Скорость чтения же сравнима с raid0. Напомню, что при этом мы еще и половину объёма дисков потеряем.

Есть еще один вариант программной реализации raid0, но уже средствами самой btrfs. С документации есть два параметра, которые могут повлиять на быстродействие и надёжность. data type — способ хранения данных. Влияет и на скорость доступа и на надёжность сохранения данных. Есть варианты: raid0, raid1, raid10 и single. И metadata profile — способ хранения метаданных. Он в большей степени влияет на возможность восстановления данных в случае мелких сбоев. Есть варианты: raid0, raid1, raid10, single и dup. Собственно, наблюдаем уже знакомые raid0 и raid10. Третий параметр, который скромно заявляет о возможном росте производительности при работе с файлами до 1GB — mixed. Для нас его влияние не очевидно.
Параметры задаются при создании файловой системы.

# mkfs.btrfs -d raid0 -m raid1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

adding device /dev/sdd1 id 2
adding device /dev/sde1 id 3
adding device /dev/sdf1 id 4
fs created label (null) on /dev/sdc1
        nodesize 4096 leafsize 4096 sectorsize 4096 size 3.64TB
Btrfs Btrfs v0.19

Если надумаете использовать mixed, то учтите, что типы хранения данных и метаданных должны быть одинаковыми.
Обратите внимание, что единого устройства как при использовании raid здесь не получается. Монтировать можно любой раздел из использованных для файловой системы. Например, mount /dev/sdc1 /mnt/raid0

В общем-то, цифры получились весьма похожие с raid0 в исполнении md. Чтение 198MB/sec и запись 216MB/sec. Пики чтения чуть меньше 700MB/sec. Средняя скорость только чтения или только записи 660MB/sec, что очень приятно удивило.

При создании раздела с -m raid0 скорости совместного доступа немного возрастают. Чтение 203MB/sec и запись 219MB/sec. А вот раздельные чтение/запись немного уменьшились 654MB/sec.

В общем и целом можно рекомендовать использовать чистый btrfs без дополнительных прослоек, которые могут быть и точками отказа.

Еще существует возможность хранения данных в lvm в режиме striping. Это очень близкий аналог raid0. Однако, у автора с lvm не складываются отношения уже не первый год. Поэтому такой вариант повышения производительности не рассматривался чисто по субъективным причинам.

Ну и напоследок неудачный эксперимент с raid10 в btrfs:

# mkfs.btrfs -L raid10 -d raid10 -m raid10 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/
sdf1

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

adding device /dev/sdd1 id 2
adding device /dev/sde1 id 3
adding device /dev/sdf1 id 4
fs created label raid10 on /dev/sdc1
        nodesize 4096 leafsize 4096 sectorsize 4096 size 3.64TB
Btrfs Btrfs v0.19

Порадовало то, что создание заняло пару секунд. Это вызывает скорее вопросы, нежели радость.
Чтение 122MB/sec и запись 127MB/sec. Раздельные чтение/запись 657MB/sec. Т.е. не годится для нашей задачи, хотя скорость раздельных операций и удивляет и радует.

Для душевного успокоения коллег был проведён тест с ext4 поверх raid0. Результаты ожидаемы.

# mkfs.ext4 /dev/md0 -L raid0
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=raid0
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=256 blocks, Stripe width=1024 blocks
244195328 inodes, 976760832 blocks
48838041 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
29809 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Проведём небольшой тюнинг, который благоприятно повлияет на производительность:

tune2fs -O extents,uninit_bg,dir_index /dev/md0
tune2fs -o journal_data_writeback
tune2fs -m 0 /dev/md0
mount /dev/md0 raid0 -o acl,user_xattr,noatime,nodiratime,barrier=0,commit=0

Результаты плачевные для нашей задачи. Чтение и запись: 60MB/sec и 86MB/sec. Только чтение/запись 535MB/sec.

Выводы очевидны. Btrfs намного выгоднее для нашей задачи чем ext4, а raid0 быстрее raid10.

Осталось только добавить, что кроме рабочих обработчиков данных использовались и сторонние утилиты.
Для синтетических тестов использовались stress и bonnie++
Фактические данные о чтении/записи собирались при помощи sysstat.

Нифга себе воруют…

Купил сегодня винт WD Scorpio Black WD7500BPKT, 750Гб, HDD, SATA II:

Disk /dev/sdc: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, всего 1465149168 секторов
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf8326998

Создадим раздельчик:

Команда (m для справки): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Номер раздела (1-4, по умолчанию 1): 
Используется значение по умолчанию 1
Первый sector (2048-1465149167, по умолчанию 2048): 
Используется значение по умолчанию 2048
Last sector, +sectors or +size{K,M,G} (2048-1465149167, по умолчанию 1465149167): +700G
Значение за пределами диапазона.
Last sector, +sectors or +size{K,M,G} (2048-1465149167, по умолчанию 1465149167): 680G
Значение за пределами диапазона.
Last sector, +sectors or +size{K,M,G} (2048-1465149167, по умолчанию 1465149167): +650G
Partition 1 of type Linux and of size 650 GiB is set

Сабж!
Заявлено 1465149168 секторов, причём первые 2048 нельзя заюзать.
Итого (1465149168 — 2048) / 2 = 732573560 килобайт. Уже на глазок нет 750Gb. Делим на 1024 и еще раз на 1024 и получаем 698,636Gb.
-7% Неслабо…

DNSSEC на практике у регистратора доменов

Историческая справка

Система доменных имён (DNS) является одним из важнейших и основных интернет-сервисов, однако на момент её разработки безопасность не была главной целью. С развитием Интернет, однако, обнаружились и уязвимости в системе DNS. Достоверность ответа DNS сервера не проверяется, что позволяет подменить ответ сервера, перенаправив запрос пользователя на произвольный IP адрес. Уязвимы оказались и кэширующие DNS серверы интернет-провайдеров из-за возможности заполнения кэша DNS сервера данными, не исходящими от авторитетного DNS источника (атака Каминского).

Нельзя, впрочем, сказать, что о безопасности DNS вообще не задумывались до текущего времени. Серьёзные недостатки в безопасности этой системы были выявлены ещё в 1990 году Стивом Белловином (Steve Bellovin). Исследования в этой области начались со времён публикации доклада в 1995 году, что вызвало публикацию IETF первых спецификаций на эту тему (RFC 2065) в 1997 году. Первые попытки реализации этой спецификации привели к появлению новой спецификации (RFC 2535) в 1999 году. Именно на спецификации IETF RFC 2535 и была запланирована реализация DNSSEC, однако у этой спецификации были очень серьёзные проблемы с масштабированием на весь интернет. К 2001 году стало окончательно ясно, что эта спецификация была непригодна для крупных сетей. Это, в свою очередь, вызвало возникновение новых спецификаций (RFC 4033, 4034 4035) с принципиальными изменениями DNSSEC (DNSSEC-bis), новая версия которой устраняет основную проблему предыдущей реализации и, хотя в новой спецификации клиентам и необходимо совершать дополнительные действия для проверки ключей, тем не менее вполне пригодна для практического применения.

К сожалению, как это обычно и случается, недостатки DNSSEC являются продолжением её достоинств. Подписание и проверка данных DNS создают дополнительные накладные расходы, что отрицательно сказывается на производительности сети и серверов. К примеру, в среднем зона DNSSEC в 7-10 больше по размеру своего DNS эквивалента. Генерация и проверка подписей отнимает значительное время ЦПУ. Подписи и ключи занимают на порядок больше места на диске и в оперативной памяти, чем сами данные.

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

Наши дни

Теперь нужно понять ненужность данной технологии в рунете. Вспомним, что в зону .SU DNSSEC внедрили в октябре 2011 года, в зону .РФ — в ноябре 2012, .RU — в декабре 2012. Теперь попробуйте вспомнить хоть один домен подписанный DNSEC. Не можете? 😉 Это ожидаемо. На момент написания этой статьи из трёх регистраторов заявивших о внедрении у себя DNSSEC только один (и это Регтайм) подписал свой основной домен. К этому можно добавить, что за всё время существования DNSSEC количество вопросов от пользователей о внедрении этой технологии можно пересчитать по пальцам одного человека. Прямо скажем — не густо.

Тогда возникает логичный вопрос: Зачем внедрять? Затем, что Регтайм всегда был и остаётся пионером и первооткрывателем во многим вопросах DNS. Внедрение DNSSEC, как штатной фишки, очередной шаг. Причём не только для отечественных зон, но и для многих других.

На этом предлагаю закончить с теорией и философией. Теперь рассмотрим собственно использование DNSSEC на собственных name серверах.

Практические работы

Для того чтобы DNSSEC начал использоваться как задумано авторами нужны следующие компоненты:

— подписанная зона первого уровня (у нас есть отечественные .RU .SU и .РФ)
— домен в этой зоне (у нас есть webnames.ru)
— авторитарные DNS серверы для нашего домена (имеются)
— рисолвер (кеширующий DNS сервер)

Текущей стабильной версией Debian является Squeeze уже 6.0.7. Его и продолжим использоваться в качестве базы. В качестве собственно DNS сервера у нас bind9.

Опустим подробности установки и настройки собственно bind9. Ставится он просто:

aptitude install bind9

Компоненты для работы с DNSSEC:

aptitude install dnssec-tools libcrypt-openssl-random-perl

Все конфиги по умолчанию находятся в /etc/bind/
Здесь нас интересуют опции в named.conf.options. В них нужно добавить:


dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

После этого нужно перечитать конфиги или перезагрузить bind. Тут кому как нравится: rndc reconfig или /etc/init.d/bind9 restart

Для простоты внедрения будем использовать zonesigner. Это всеобъемлющая утилита, которая подписывает зону за один проход. Но есть и более сложный путь, но зачем он нужен? 😉

Забегая вперёд скажу, что в процессе своей работы zonesigner создаёт десяток файлов и рациональнее складывать их отдельно, а не в общий каталог с зонами. Да и зоны лучше не складывать в один каталог. Это не вызывает проблем есть у вас всего несколько доменов. Но если у нас более 150 тысяч зон на каждом сервере, то надо как-то оптимизировать их хранение, иначе возникают адские накладные расходы.

В процессе эволюции мы имеем следующую иерархию зон: auto/ru/w/e/b/n/webnames.ru. Для zonesigner была создана аналогичная параллельная ветвь: dnssec/ru/w/e/b/n/webnames.ru/

Первоначальная генерация подписанной зоны выглядит так:


mkdir -p /var/named/dnssec/ru/w/e/b/n/webnames.ru/
cd /var/named/dnssec/ru/w/e/b/n/webnames.ru/
zonesigner -genkeys -usensec3 -zone webnames.ru /var/named/auto/ru/w/e/b/n/webnames.ru

На выходе получим что-то типа:

        if zonesigner appears hung, strike keys until the program completes
        (see the "Entropy" section in the man page for details)

Generating key pair.....++++++ .........................................................................++++++ 
Generating key pair..++++++ ...++++++ 
Generating key pair....+++ .........+++ 
Verifying the zone using the following algorithms: RSASHA256.
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 1 stand-by, 0 revoked

zone signed successfully

webnames.ru:
        KSK (cur) 02110  -b 2048  02/22/13      (webnames.ru-signset-00003)
        ZSK (cur) 21834  -b 1024  02/22/13      (webnames.ru-signset-00001)
        ZSK (pub) 51069  -b 1024  02/22/13      (webnames.ru-signset-00002)

zone will expire in 4 weeks, 2 days, 0 seconds
DO NOT delete the keys until this time has passed.

А теперь убедимся, что файлов создано много:


$ls -1
dsset-webnames.ru.
Kwebnames.ru.+008+02110.key
Kwebnames.ru.+008+02110.private
Kwebnames.ru.+008+21834.key
Kwebnames.ru.+008+21834.private
Kwebnames.ru.+008+51069.key
Kwebnames.ru.+008+51069.private
webnames.ru.krf

А рядом с файлом обычной зоны появился второй файл webnames.ru.signed и он более чем в 20 раз больше оригинала — 32669 байт против 1369. И еще 7520 байт на служебные файлы указанные выше. Т.е. мы получили в 30 раз больше информации. Правда зона webnames.ru совсем маленькая и такой прирост не сильно тяготит.

На всякий случай проверим новый файл зоны на ошибки:


$ donuts --level 8 webnames.ru.signed webnames.ru
0 errors found in webnames.ru.signed

«—level» — это уровень выдачи ошибок. Когда ошибок нет, то в нём особого смысла нет. Кстати, есть очень простой способ напороться на эти ошибки. Например, добавив NS запись со сторонним DNS сервером.
Добавим в зону запись bad NS ns1.gde-to-tam-daleko.ru и обновимся:

zonesigner -zone webnames.ru /var/named/auto/ru/w/e/b/n/webnames.ru

Обратите внимание, что править нужно всегда обычную зону, а подписанную DNSSEC нужно обновлять именно так.

Теперь проверим на ошибки:

$ donuts --level 8 webnames.ru.signed webnames.ru 
bad.webnames.ru:
  Warning:     Only 1 NS record(s) for bad.webnames.ru found, but at least
               2 are suggested/required

bad.webnames.ru:
  Error:       sub-domain bad.webnames.ru is not securely delegated.  It is
               missing a DS record.

2 errors found in webnames.ru.signed

Вот так. 🙂 Это усложнение структуры стоит учитывать в своей практике. Если вдумчиво читать, то становится понятно, что именно нужно делать. Во-первых, добавить вторую NS запись, а во-вторых, добавить DS запись для поддомена.

Но откуда же у нас эти DS берутся? Выше у нас показан файл dsset-webnames.ru. Его содержимое таково:

webnames.ru.            IN DS 2110 8 1 4F38DB26A26DDFFB0A84052472D1AF70DAA595D7
webnames.ru.            IN DS 2110 8 2 0CC3937FE64FD4BF3B8282748F93C566870F4FCD254BCF0D91DBCF50 23D6D28C

Именно эти записи нужно передать регистратору домена, чтобы он их отправил в реестр зоны. И они же нужны для того чтобы donuts перестал выдавать ошибки для NS записей.
Процедура передачи у разных регистраторов разная. На Webnames.Ru, например, в разделе «Управления доменом» «Личного кабинета» есть специальный пункт «DNSSEC» где можно включить и выключить собственно поддержку DNSSEC, а также увидеть имеющиеся DS записи и при необходимости внести новые.

Теперь вспомним о том, что все криптографические ключи имеют срок годности. Неплохо бы автоматизировать и их замену… Радует, то что есть специальный демон rollerd. В то же время печалит, то что для этого демона нет init-скрипта. Поэтому придётся его написать самостоятельно. Можно, конечно, и не писать, а обойтись колхозными методами, но это уже каждый решает сам. Еще чуть больше печалит то, что rollerd хоть и следит за ключами и заменяет их, но не может заменить их в реестре.

Сначала определимся за чем будем следить. Для этих целей есть rollinit. Он готовит для rollerd список зон за ключами которых мы собираемся следить. Давайте определимся, что список мы будем хранить в dnssec/. Соответственно, добавим туда нашу подписанную зону:


rollinit -zonefile /var/named/auto/ru/w/e/b/n/webnames.ru.signed -keyrec /var/named/dnssec/ru/w/e/b/n/webnames.ru/webnames.ru.krf -admin support@webnames.ru webnames.ru >> /var/named/dnssec/rollrec

Если кто-то читая это уже наклепал подписанных зон, то нужно их все добавить в этот же список либо следить за ключами вручную. 😉

После этого нужно запустить rollerd. Вот обещанный init-скрипт: /etc/init.d/rollerd

#!/bin/bash

### BEGIN INIT INFO
# Provides:          rollerd
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO

PATH=/bin:/usr/bin:/sbin:/usr/sbin
DESC="DNSSEC-Tools daemon to manage DNSSEC key rollover"
NAME=rollerd
DAEMON=/usr/sbin/$NAME
SCRIPTNAME=/etc/init.d/$NAME
CONF=/var/named/dnssec/rollrec
PIDFILE=/var/run/rollerd.pid

[ -x "$DAEMON" ] || exit 0
. /lib/init/vars.sh
. /lib/lsb/init-functions
[ -f $CONF ] || exit 0

start_rollerd () {
        [ -f $PIDFILE ] && return 1
        $DAEMON -rrfile $CONF -directory /etc/bind -pidfile $PIDFILE
}

stop_rollerd () {
        if [ -s $PIDFILE ]; then
                PID=`cat $PIDFILE`
                kill $PID && rm -f $PIDFILE
                sleep 3
                [ -d "/proc/$PID" ] && return 1
                return 0
        fi
        PID=`ps xa | grep -v grep | grep $DAEMON | awk '{print $1}'`
        [ -z "$PID" ] && return 0
        kill $PID
        sleep 3
        [ -d "/proc/$PID" ] && return 1
        return 0
}

case "$1" in
        start)
                log_daemon_msg "Starting $DESC" "$NAME";
                start_rollerd;
                log_end_msg $?;
                ;;
        stop|force-stop)
                log_daemon_msg "Stopping $DESC" "$NAME";
                stop_rollerd;
                log_end_msg $?;
                ;;
        restart)
                log_daemon_msg "Restarting $DESC" "$NAME";
                stop_rollerd;
                start_rollerd;
                log_end_msg $?;
                ;;
        *)
                echo "Usage: $0 ";
                exit 1;
                ;;
        esac;

exit 0;

Готовим его к запуску, автозапуску и запускаем.


chmod 755 /etc/init.d/rollerd
update-rc.d rollerd defaults
/etc/init.d/rollerd start

Если кто-то совсем расстроился, что полную ротацию ключей автоматизировать невозможно, то это зря. Можно, но уже при помощи почтового демона. У нас используется sendmail. Поэтому при помощи smrsh можно сделать почти всё что угодно. Делается это довольно просто. В /etc/mail/sendmail.mc добавляем следующие строки перед первым MAILER’ом:


FEATURE(`virtusertable', `hash /etc/mail/virtusertable')dnl
VIRTUSER_DOMAIN_FILE(`/etc/mail/local-host-names')dnl

В /etc/mail/virtusertable добавляем:
dnssec@localhost dnssec
Этим мы создали виртуальный почтовый ящик dnssec@localhost и отправили всю входящую почту на системного юзера dnssec.

В /etc/aliases добавляем:
dnssec: "|/etc/mail/smrsh/dnssec"
Этим мы всю входящую почту юзеру dnssec отправили через пайп (т.е. в его STDIN) в скрипт /etc/mail/smrsh/dnssec

А уж в скрипте /etc/mail/smrsh/dnssec мы можем делать всё что хотим.
Стоит отметить, что скриптом это называется условно. Это может быть и бинарник.

Теперь перезапустим sendmail и все изменения вступят в силу:
/etc/init.d/sendmail restart

При этом всём не забудьте, что при использовании smrsh нужно переинициировать /var/named/dnssec/rollrec с адресом dnssec@localhost. Т.е. примерно так:


rollinit -zonefile /var/named/auto/ru/w/e/b/n/webnames.ru.signed -keyrec /var/named/dnssec/ru/w/e/b/n/webnames.ru/webnames.ru.krf -admin dnssec@localhost webnames.ru >> /var/named/dnssec/rollrec

Сам скрипт /etc/mail/smrsh/dnssec приводить не имеет смысла, поэтому ограничимся обёрткой на bash без функционала.
Само письмо выглядит примерно так:

From: root
To: dnssec@localhost
Subject: assistance needed with KSK rollover of zone webnames.ru

The zone "webnames.ru" is in the middle of KSK rollover. In order for rollover
to continue, its keyset must be transferred to its parent.

Парсить его можно, например, так:

#!/bin/bash

while read L; do
    if [ "${L:0:9}" == "Subject: " ]; then
        for W in $L ; do echo -n '' ; done
        echo "Domain $W"
    fi
done

Т.е. после разбора поля Subject по словам получим в результате имя домена (в переменной W) для которого нужно послать обновлённые DS записи в реестр.

Теперь настроим последний компонент DNSSEC — рисолвер, он же кеширующий DNS сервер. И здесь всё тоже очень просто. Если взять тот же самый bind9, то в тот же самый файл /etc/bind/named.conf.options нужно добавить те же опции и перезагрузить bind:


dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/etc/init.d/bind9 restart

Теперь на рабочем компе нужно прописать в качестве DNS сервера наш рисолвер и наслаждаться DNSSEC’ом.

Вот и всё.