Настройка DNS-сервера (bind) в CentOS/RHEL 7

BIND (Berkeley Internet Name Daemon) так же известен как named – это самый известный и самый используемый DNS-сервер в интернете. Я постараюсь описать процесс установки и настройки этого сервиса в chroot-окружении (chroot – операция изменения корневого каталога в Unix-подобных операционных системах. Программа, запущенная с изменённым корневым каталогом, будет иметь доступ только к файлам, содержащимся в данном каталоге. Поэтому, если нужно обеспечить программе доступ к другим каталогам или файловым системам (например, /proc), нужно заранее примонтировать в целевом каталоге необходимые каталоги или устройства.).

  • Сначала установим сам сервис и сопутствующие утилиты:
  •  

  • Теперь подготовим chroot-каталог, подмонтировав необходимые файлы и папки, и проведём первоначальную настройку DNS-сервера:
  • Note: в acl «xfer» я добавил IP-адреса серверов, которые будут secondary-серверами для моих зон. Если вы на своём DNS-сервере никакие зоны хостить не собираетесь – этот блок можно оставить пустым, иначе впишите туда IP-адреса secondary-серверов для ваших зон.
     

  • Настраиваем firewall для работы DNS-сервера:
  •  

  • Включаем автозапуск DNS-сервера и запускаем сервис:
  • Note: в качестве 2-го и 3-го DNS-сервера лучше вписать IP-адрес DNS-серверов вашего провайдера, так резолвинг будет проходить чуть быстрее.
     

  • Проверяем работоспособность:
  •  

  • Если в предыдущем пункте никаких ошибок не возникло – добавим функционала, настроим сервер как master для нескольких зон (если сервер нужно настроить как slave для зон, этот пункт пропускаем и читаем следущий):
  •  

  • Если сервер нужно настроить как slave, делаем следующее:

Вот и всё, DNS-сервер настроен и готов к работе!

Comments

  1. Алексей
    22.04.2015 - 21:45

    Бегло пробежав по инструкции, оставлю немного критики:
    1) Пакет named-chroot подразумевает что chroot окружение со всем необходимым будет создаваться и монтироваться само в директории /var/named/chroot
    Следовательно все остальные манипуляции излишни. И редактировать файлы рекомендуется так же в /var/named, а не в /var/named/chroot. Главное — включать и запускать только лишь сервис named-chroot, но не named.
    Плюс рекомендуется (и я не вникал почему, полагаю из соображений безопасности) редактировать зоны в chroot окружении используя копии, например
    # vim -c «set backupcopy=yes» /etc/named.conf
    Подробности о named-chroot в rhel 7 здесь https://access.redhat.com/articles/770133

    2) setsebool -P named_write_master_zones=1 рекомендуется использовать только в случае динамических зон. Для slave зон у named разрешения и так есть, а это правило для перезаписи bind’ом мастер зон.
    Часть с chcon вообще бессмысленна, так как если класть конфиги туда куда полагается — проблем и не будет, плюс chcon делает смену контекста временно, и если сделать restorecon то метка слетит на дефолтную (и это может случится без вашего участия, если системе, например, после восстановления ошибок фс понадобится переразметить контексты). В данном случае это вообще ну нужно, но контекст менять нужно через semanage.

    3) Файлы включенные в основную конфигурацию named.conf рекомендуется помещать в директорию /etc/named/. В вашем случае будет /etc/named/named.zones. Подробности тут https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-BIND.html

    4) Рекомендуется использовать утилиту rndc для всего что она поддерживает, в том числе
    rndc reconfig
    rndc reload
    rndc reload zone
    и тд. Смысл в том что дёргать каждый раз systemctl reload named не стоит, плохая практика. Плюс в rhel\centos о конфигурации этого самого rndc позаботились до нас и настраивать для использования на этом хосте не нужно. И создать заготовок зоны так же можно через rndc
    И кстати для удобства можно значения в SOA записи делать не в секундах, а в более понятных величинах — 1d 1h 1w и тд. Передаваться оно будет всё равно в секундах, но конфигурировать легче.

    За исключением этих мелочей — это прекрасная статья, спасибо. И меня впечатлило следование RFC 4408 с TXT и SPF записями.

  2. Доброго времени!
    столкнулся с непривычной задачкой, которую почти решил. Есть только одно но
    Подробности тут http://forum.learncisco.ru/index.php/topic,405.0.html

  3. Алексей
    01.06.2015 - 13:55

    Я тут прочитал заново rfc, и RFC7208 http://tools.ietf.org/html/rfc7208 полностью заменило RFC4408, SPF записи признаны deprecated. И SPF запись следует убрать из зон.

Добавить комментарий