Компания NLNet Labs объявила (http://open.nlnetlabs.nl/pipermail/nsd-users/2013-October/00...) о выпуске DNS-сервера NSD 4.0 (http://www.nlnetlabs.nl/projects/nsd/), спустя семь лет с момента релиза NSD 3.0. Сервер поддерживает работу только в авторитативном режиме (обработка DNS-зон) и максимально оптимизирован для решения данной задачи. Стабильность и надёжность NSD подтверждена использованием данного DNS-сервера на нескольких корневых серверах DNS и серверах, обслуживающих домены первого уровня.
Код NSD распространяется под лицензией BSD.
На уровне поддержки протоколов NSD полностью совместим с другими авторитативными и рекурсивными серверами DNS, а также может использоваться для DNSSEC (с поддержкой NSEC3). На уровне файлов зон NSD совместим с BIND и может работать файлами зон BIND, без необходимости внесения в них изменений. Исходные файлы зон компилируются в бинарное индексированное представление, которое обеспечивает минимальное время запуска, оптимальную производительность и гарантию отсутствия ошибок (все проблемы выявляются на стадии компиляции).Ключевые особенности выпуска NSD 4.0:
- Значительное повышение производительности, по сравнению с NSD 3;- Возможность динамического изменения конфигурации и управления работой DNS-сервера на лету при помощи новой утилиты nsd-control (например, при помощи команд addzone и delzone можно добавлять/удалять зоны без перезапуска демона, а командой применить изменения в nsd.conf). Поддержка утилиты nsdc прекращена (для перезапуска и остановки следует использовать nsd-control или kill -HUP/kill -TERM). Также прекращена поддержка запускаемой через cron команды "nsdc patch", вместо которой для создания файлов зон предлагается использовать операцию "nsd-control write". Nsd-control может использоваться для управления не только локальным сервером, но и удалённым с использованием аутентификации по ключам шифрования (для генерации ключей подготовлена утилита nsd-control-setup);
- Изменения формата базы nsd.db и перевод внутренних структур на Radix Tree. Новый формат поддерживает операции чтения и записи, и предоставляет средства автоматической упаковки после внесения изменений, что избавляет от необходимости периодического выполнения "nsdc patch". Для доступа к nsd.db теперь используется маппинг в память. Обеспечена поддержка оценки изменения файлов зон с последующим обновлением в базе только изменившихся данных при инициировании операции обновления конфигурации. При этом обновление базы теперь выполняется на лету самим демоном, без необходимости использования компилятора zonec;
- Поддержка технологии RRL (http://www.opennet.me/opennews/art.shtml?num=37962) (Response Rate Limiting) для ограничения интенсивности отправки ответов в привязке к адресу получателя (ограничения действуют только на исходящие запросы и не влияют на входящие). RRL является одним из способов противодействия использования DNS-сервера в качестве усилителя (http://www.opennet.me/opennews/art.shtml?num=36525) в DDoS-атаках;
- Средства для использования NSD для обслуживания огромного числа зон;
- Добавлена директива pattern для определения шаблонов типовых элементов конфигурации зон. Шаблоны могут включаться в состав зон или в состав других шаблонов;
- Директива tcp-count, определяющая максимальное допустимое число одновременных запросов, теперь может принимать значения больше 1000. Добавлена поддержка epoll/kqueue через libevent.
URL: http://open.nlnetlabs.nl/pipermail/nsd-users/2013-October/00...
Новость: http://www.opennet.me/opennews/art.shtml?num=38304
Надеюсь он наконец-то будет работать со строками длиной более 1024.
А начем бы сделать днс с поддрежкой географии. Чтобы для америки одно отдавал, а для европы другое?
В твоем случае тока Bind
Используйте view в BIND: http://www.opennet.me/tips/info/297.shtml
Про вьюхи всем знакомо. Но бинд на большом количестве зон, а если еще и на большом количестве ip - это ад
>Про вьюхи всем знакомо. Но бинд на большом количестве зон, а если еще и на большом количестве ip - это адДа ладно?
# rndc status
CPUs found: 8
worker threads: 8
UDP listeners per interface: 8
number of zones: 133077
>>Про вьюхи всем знакомо. Но бинд на большом количестве зон, а если еще и на большом количестве ip - это ад
> Да ладно?
> # rndc status
> CPUs found: 8
> worker threads: 8
> UDP listeners per interface: 8
> number of zones: 133077Сколько минут на запуск?
Минуты 2-3, с SSD-дисков. А в чём проблема? Вы перезагружаете днс-сервера раз в час, потому что это весело?
главное не забывать указать зону, при rndc reload ? :)
>>Про вьюхи всем знакомо. Но бинд на большом количестве зон, а если еще и на большом количестве ip - это ад
> Да ладно?
> # rndc status
> CPUs found: 8
> worker threads: 8
> UDP listeners per interface: 8
> number of zones: 133077Ну во первых это не много зон. Во вторых - сколько айпи слушает бинд ? Ну и да, две минуты на запуск с ссд - это дофига имхо. Учитывая что эти две минуты у вас ДНС вообще не отвечает.
А у вас только один DNS сервер? ;)
Тонко :)
>>Про вьюхи всем знакомо. Но бинд на большом количестве зон, а если еще и на большом количестве ip - это ад
> Да ладно?
> # rndc status
> CPUs found: 8
> worker threads: 8
> UDP listeners per interface: 8
> number of zones: 133077Угости статой по кол-ву в процентах запросов, которые идут с гугл паблик днс
PowerDNS с геобэкендом не труЪ, не?По теме - жду в портах)
Люто плюсую!
Не очень удобно в плане конфигурирования гео зон. Хотелось бы что-то типа nsd-control.
> А начем бы сделать днс с поддрежкой географии. Чтобы для америки одно
> отдавал, а для европы другое?include «/etc/bind/geoip/GeoIP.acl»;
zone «domain.org.ua» {
type master;
file «/etc/bind/zones/master/domain.org.ua»;
};
view «RU» {
match-clients { RU; };
recursion no;
zone «domain.org.ua» {
type master;
file «/etc/bind/zones/master/domain.org.ua.ru»;
};
};
>> domain.org.ua.ruТонко
gdnsd
> А начем бы сделать днс с поддрежкой географии. Чтобы для америки одно
> отдавал, а для европы другое?gdnsd
Для ускорения Bind можно организовать через zram + losetup = md весьма пульный ускоритель, тогда работа bind будет мерятся на наносекунды.. в принципе так можно что разгонять.. :)
не пользовал NSD, интересно чем отличается от bind? ... в плане юзабельности и эффективности..
>> Для ускорения Bind можно организовать через zram + losetup = md весьма пульный ускорительПростите, это не ускоритель а костыль и хак + фиксированный обьем память расходуеться
насчет "костыля" .. соглашусь отчасти, но в ситуации когда есть необходимость решения, можно много чего в Линуксе костылями обзывать.. на то он и Линукс, вы имеете конструктор, добротный, пользуйтесь.. что касается хака.. гм, это вы про что?
про модуль zram - http://ru.wikipedia.org/wiki/ZRam
решение человека применительно к ситуации: http://habrahabr.ru/post/172137
ИМХО хаком называть.. как то странно..
что касается расхода памяти.. дык ема е а, что если ее не хватает, купить и зафиксировать объем под необходимые нужды проблема? .. ведь вы ее все равно выделяете когда ставите службы и программы, просто заранее предполагая сколько ее понадобиться для нужд системы в целом..
я не вижу здесь каких либо глобальных проблем..
у меня на некоторых серверах с виртуализацией используется такая технология..
пока тьфу, тьфу.. при чем уже год как.. и даже базы крутятся в таком..
Вообще скажу так, когда возникает необходимость решения проблемы, любое решение которое будет эффективным - является успешным. Что касается "красоты", ни кто не запрещает это потом довести до ума.. без "Хака" .. :)
> что касается расхода памяти.. дык ема е а, что если ее не
> хватает, купить и зафиксировать объем под необходимые нужды проблема? .. ведь
> вы ее все равно выделяете когда ставите службы и программы, просто
> заранее предполагая сколько ее понадобиться для нужд системы в целом..Если бинду перестанет хватать памяти он может выйти за пределы стека
"Если бинду перестанет хватать памяти он может выйти за пределы стека"
я могу чего то не знать, но ИМХО могу предполагать, что с ваших слов если bind-у не хватит памяти то вместо свопа он полезет в любую часть памяти? по сути вопроса.. в unix или linux если процесс держит область памяти которая зарезервирована для его нужд, кто то может переступить через порог и занять то что ему покажется "свободным".. по моему это называется bag и явно сложит систему... что то или я не понимаю или вы не то говорите..
о аналогичных косяках в ядре в свое время было описание, и на сколько мне память не изменяет баг перехлеста областей памяти был закрыт.. но могу я и ошибаться.. тогда это проблема.. :(