Что-то не так в вашем королевстве — ~90 тысяч зон на четырех гигах оперативки нормально живут и не особо напрягают сервер. Точно так же как и меньшее кол-во зон при большом (~10 млн) общем кол-ве записей. Единственная проблема — долгий старт. Это верно для BIND без DLZ.
По моим данным, при прочих равных BIND обслуживает процентов на 30 меньше запросов в секунду чем NSD. Судя по тестам DLag'а DLZ с мускулем делает этот разрыв еще больше. Что в общем-то очевидно, так как DLZ на каждый запрос лезет в базу, а скорости это не добавляет. Вывод из этого можно сделать такой: если планируется большой qps, DLZ использовать нельзя.
Плюс невозможность сделать нормальный master-slave, из-за чего возникает необходимость держать на каждом сервере по БД и реплицировать ее. Плюс нельзя использовать динамические обновления.
Короче на мой взгляд гораздо правильнее использовать, скажем, динамические обновления (которые с той же базой увязать совершенно несложно), IXFR и rndc addzone/delzone.
Зачем все это: в DNSSec есть один вопрос, который не могут решить уже давно — защищенность последней мили, то есть трафика от резолвера к клиенту. Все дело в том, что большинство stub-резолверов валидацией не занимаются, поэтому против него можно провести атаку отравления кэша. Вот для предотвращения этой атаки и идут на подобные ухищрения.
Не врите, в Windows Server 2008 R2 имеется поддержка только rsasha1, в свете того, что корневая зона подписана rsasha256, становится очевидно, что microsoft dns не поддерживает dnssec (то бишь микрософтовский резолвер не сможет выстроить полную цепочку доверия). Вдобавок, если попытаться провалидировать rsasha1 + nsec3 + opt-out, ответом будет servfail, что несколько расходится с написанным на технете.
Польза DNSSEC в том, что если ваш резолвер установил цепочку доверия, то ответу авторитетного сервера он может доверять настолько, насколько доверяет серверам корневой зоны. Соответственно, если вы доверяете этому резолверу, то сможете утверждать, что ответ к вам пришел именно от нужного сервера, а не от поддельного. Естественно, подписывать свои зоны или нет — личное дело каждого.
Сам факт подписанности SU в том, что очевидно, это первый шажок к подписанным RU и РФ. Результат — все желающие использовать DNSSEC получат хороший повод его внедрить.
На мой взгляд подпись SU — проба пера в продакшне, ведь RU больше SU примерно в 30 раз.
Я говорил про десятки тысяч зон. На одном сервере пришлось вытесать костыль чтобы как раз BIND 9.4 запускался после sshd, иначе во время его старта (~70-80k зон) на сервер было не попасть.
AXFR — да, можно сделать, однако на том же сайте можно прочитать: While this method of data replication is necessary when not using DLZ, and is in fact the «standard» way (according to the RFC's) of propogating data, it is not how data replication should be handled with DLZ.
Про IXFR: zone tranfers with DLZ require a full zone transfer — resulting in a lot of wasted data being sent across the wire.
То есть перекачивается вся зона вместо небольшого числа записей, плюс перекачивается она при наступлении expire. В общем, не самое удачное решение. Если нужна база, лучше генерить зоны из нее чем-то внешним, а распространение отдать на откуп DNS'ам, они справятся лучше.
И да, IXFR можно тоже сделать, но схема получается настолько «via anus», что я ее даже врагу не пожелаю.
Это костыль, и он довольно-таки кривой. Кривости следующие:
1. На один запрос к ДНС получается несколько запросов к базе, почему — черт знает;
2. Нельзя реализовать принцип master-slave, BIND не умеет выгружать зону из базы;
3. Из-за пункта 2 надо всем серверам давать доступ к базе вместо того чтобы пользоваться AXFR/IXFR;
4. Из-за пункта 3 вместо нескольких независимых DNS серверов, каждый из которых при недоступности мастера будет отвечать на запросы к зоне еще в течение expire периода, получаем несколько серверов завязанных на одну базу данных.
Не совсем понятна цель. На cpan.org огромное кол-во модулей для чтения, парсинга и написания DNS зон, а уж увязать это с базой проблем вообще никаких. Впрочем, свой велосипед — это всегда интересно.
А почему не используете rndc чтобы перечитать конфиг/перегрузить зоны BIND'а без его рестарта? Насколько я понимаю, много мелких зон, в этом случае BIND довольно долго стартует, ISC только в последних версиях ускорили этот процесс.
Плюс невозможность сделать нормальный master-slave, из-за чего возникает необходимость держать на каждом сервере по БД и реплицировать ее. Плюс нельзя использовать динамические обновления.
Короче на мой взгляд гораздо правильнее использовать, скажем, динамические обновления (которые с той же базой увязать совершенно несложно), IXFR и rndc addzone/delzone.
Сам факт подписанности SU в том, что очевидно, это первый шажок к подписанным RU и РФ. Результат — все желающие использовать DNSSEC получат хороший повод его внедрить.
На мой взгляд подпись SU — проба пера в продакшне, ведь RU больше SU примерно в 30 раз.
While this method of data replication is necessary when not using DLZ, and is in fact the «standard» way (according to the RFC's) of propogating data, it is not how data replication should be handled with DLZ.
Про IXFR:
zone tranfers with DLZ require a full zone transfer — resulting in a lot of wasted data being sent across the wire.
То есть перекачивается вся зона вместо небольшого числа записей, плюс перекачивается она при наступлении expire. В общем, не самое удачное решение. Если нужна база, лучше генерить зоны из нее чем-то внешним, а распространение отдать на откуп DNS'ам, они справятся лучше.
И да, IXFR можно тоже сделать, но схема получается настолько «via anus», что я ее даже врагу не пожелаю.
1. На один запрос к ДНС получается несколько запросов к базе, почему — черт знает;
2. Нельзя реализовать принцип master-slave, BIND не умеет выгружать зону из базы;
3. Из-за пункта 2 надо всем серверам давать доступ к базе вместо того чтобы пользоваться AXFR/IXFR;
4. Из-за пункта 3 вместо нескольких независимых DNS серверов, каждый из которых при недоступности мастера будет отвечать на запросы к зоне еще в течение expire периода, получаем несколько серверов завязанных на одну базу данных.
А почему не используете rndc чтобы перечитать конфиг/перегрузить зоны BIND'а без его рестарта? Насколько я понимаю, много мелких зон, в этом случае BIND довольно долго стартует, ISC только в последних версиях ускорили этот процесс.