Pull to refresh

Comments 21

Да особо-то ничего нового. Показали бы еще, как настраиваются различные вьюхи, географические ACL, системы распределенных серверов, ipv6. А так еще одна заметка для себя о том, какие строки надо вбить в конфиг очередного сервиса.
Нет ничего нового, все есть man.
Раз уж статья для новичков, то имело бы смысл расписать поля Refresh, TTL. Также был бы интересен краткий курс по записям в NS: зачем для почты нужны txt записи, к примеру и т.д.
Можно пойти еще дальше: ведение зоны не через файлы, а через СУБД, что позволяет редактировать NS-ресурсы значительно эффективнее.
В современных реалиях не помешало бы еще описание защиты от DNS-Amplf и т.д.

Целью статьи не было описать все конфигурационные файлы которые применяются, а именно запуск named сервиса. Будет время опишу все ключики к конфигурационному файлу, если такой статьи здесь еще нет.
Ну а цель моего комментария состояла не в просьбе описать все директивы конфигурационного файла.
2014-й год на дворе, декабрь месяц. Пора привыкать к

systemctl enable named.service
systemctl start  named.service

вместо
chkconfig named on
service named start
UFO landed and left these words here
Через init.d не очень можно, ибо в последнем центосе для сервисов типа bind в пакете уже нет init-скриптов.
Так что оно по-любому будет через systemd. А вот старые команды (chkconfig и service) работать будут, но исключительно как обертка для вызова systemctl
первое правило программиста «работает? ничего не трогай!»
в чем разница этих команд? если результат и там и там будет одинаковый?
Для авторитарного сервера я бы всё же выбрал NSD, а только для только рекурсивного сервера для внутренней сети — Unbound. Bind же представляется оптимальным выбором, если есть необходимость поднимать гибридный сервер — авторитарный + рекурсивный. Но это сугубо личное мнение.

По статье: стоит добавить RRL в конфигурацию. Но для этого будет недостаточно поставить Bind из репозитория, ибо в base он обновлялся очень давно. Я собирал RPM версии 9.10.1, полёт нормальный. Боты очень любят долбить DNS паразитными запросами, RRL поможет хоть немного сгладить эти пики.
UFO landed and left these words here
1. исключить 192.168.0.0/8 — это сильная заявка.
2. Почему исключен только 172.16.0.0/16 тоже не совсем ясно
3. А кто такой 180.0.0.0/4? Он вообще должен быть тогда уж 176.0.0.0/4, но за что его банить все равно не ясно.
4. А почему это одного UDP хватает? Вообще по умолчанию slave забирает зону с мастера по TCP, eсли мне склероз не изменяет.
UFO landed and left these words here
Спасибо за комментарий, учтем и исправимся.
Два момента:
1. chroot насколько я понимаю очень важно, но вот что такое и с чем его едят мне пока непонятно.
2. собственно описывал то что менял в стандартном файле, по другим ключам вы скорее всего правы, так как опыта у меня в этом деле совсем никакого. Будем читать и разбирать что за ключи и с чем их едят. Опишу как разберусь.
UFO landed and left these words here
Господи, сколько возни то.
PS, я уже лет 5+ bind в продакшене не вижу, хотя с телекомами, хостерами активно работаю. PowerDNS, NSD, да, активно пользуются. PowerDNS' ом я очень доволен, особенно в варианте пачки NS серверов с сотнями тысяч зон.
PowerDNS посмотрел, да отличная штука. Но использовать его при поддержке пары доменов клиента смысла особого нет, по крайней мере я не вижу выгоды. С NSD вообще на первый взгляд «те же яйца вид сбоку» как и bind, последний по универсальности выигрывает. Установка не сильно отличается от того что описано мной. Как всегда, истина где то в деталях, и в том что где будет использовано.
Ну если пару доменов, тогда вообще зачем его городить?
Провайдерские DNS всяко стабильнее будут.
Хотя вариантов масса, да.
о прикольно, в английской версии есть yum install bind-chroot -y типа надо делать
и rndc reload смысл которого мне не понятен сейчас
Only those users with full accounts are able to leave comments. Log in, please.