25.6.1. Обзор

По умолчанию во FreeBSD используется одна из версий программы BIND (Berkeley Internet Name Domain), являющейся самой распространенной реализацией протокола DNS. DNS - это протокол, при помощи которого имена преобразуются в IP-адреса и наоборот. Например, в ответ на запрос о www.FreeBSD.org будет получен IP-адрес веб-сервера Проекта FreeBSD, а запрос о ftp.FreeBSD.org возвратит IP-адрес соответствующей машины с FTP-сервером. Точно также происходит и обратный процесс. Запрос, содержащий IP-адрес машины, возвратит имя хоста. Для выполнения запросов к DNS вовсе не обязательно иметь в системе работающий сервер имён.

В сети Интернет DNS управляется через достаточно сложную систему авторизированных корневых серверов имён, и других менее крупных серверов имён, которые содержат и кэшируют информацию о конкретных доменах.

В этом документа рассматривается BIND 8.x, так как это стабильная версия, используемая во FreeBSD. Начиная с FreeBSD 5.3, с системой поставляется BIND9, инструкции к настройке которого находятся далее в этой главе. Пользователи FreeBSD 5.2 и предыдущих релизов могут установить BIND9 из порта net/bind9.

Протокол DNS стандартизован в RFC1034 и RFC1035.

На данный момент пакет BIND поддерживается Internet Software Consortium http://www.isc.org/.

25.6.2. Используемая терминология

Для понимания этого документа нужно понимать значения некоторых терминов, связанных с работой DNS.

Примеры зон:

• . является корневой зоной

• org. является зоной ниже корневой зоны

• example.org. является зоной под зоной org.

• foo.example.org. является поддоменом, зоной под зоной example.org.

• 1.2.3.in-addr.arpa является зоной, в которую включены все IP-адреса, формирующие пространство адресов 3.2.1.*.

Как можно видеть, уточняющая часть имени хоста появляется слева. Например, example.org. более точен, чем org., также, как org. более точен, чем корневая зона. Расположение каждой части имени хоста сильно похоже на файловую систему: каталог /dev расположен в корневой файловой системе, и так далее.

25.6.3. Причины, по которым вам может понадобиться сервер имён

Сервера имён обычно используются в двух видах: авторитетный сервер имён и кэширующий сервер имён.

Авторитетный сервер имён нужен, когда:

• нужно предоставлять информацию о DNS остальному миру, отвечая на запросы авторизированно.

• зарегистрирован домен, такой, как example.org и в этом домене требуется поставить имена машин в соответствие с их адресами IP.

• блоку адресов IP требуется обратные записи DNS (IP в имена хостов).

• резервный (slave) сервер имён должен отвечать на запросы о домене, когда основной не работает или не доступен.

Кэширующий сервер имён нужен, когда:

• локальный сервер DNS может кэшировать информацию и отвечать на запросы быстрее, чем это происходит при прямом опросе внешнего сервера имён.

• требуется уменьшение общего сетевого трафика (DNS составляет около 5% всего трафика Интернет, или чуть больше).

Например, когда кто-нибудь запрашивает информацию о www.FreeBSD.org, то обычно резолвер обращается к серверу имён вашего провайдера, посылает запрос и ожидает ответа. С локальным кэширующим сервером DNS запрос во внешний мир будет делаться всего один раз. Каждый дополнительный запрос не будет посылаться за пределы локальной сети, потому что информация уже имеется в кэше.

25.6.4. Как это работает

Во FreeBSD даемон BIND, по очевидным причинам, называется named.

Файлы зон обычно располагаются в каталоге /etc/namedb и содержат информацию о зоне DNS, за которую отвечает сервер имён.

25.6.5. Запуск BIND

Так как сервер имён BIND устанавливается по умолчанию, его настройка сравнительно проста.

Чтобы даемон named запускался во время загрузки, поместите в /etc/rc.conf следующую строку:

named_enable="YES"

Для запуска даемона вручную (после его настройки):

# ndc start

25.6.6. Конфигурационные файлы

# cd /etc/namedb
# sh make-localhost

// $FreeBSD$
//
// Refer to the named(8) manual page for details.  If you are ever going
// to setup a primary server, make sure you've understood the hairy
// details of how DNS is working.  Even with simple mistakes, you can
// break connectivity for affected parties, or cause huge amount of
// useless Internet traffic.

options {
    directory "/etc/namedb";

// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
//
//      forward only;

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the
Internet.
/*
    forwarders {
        127.0.0.1;
    };
*/

/*
     * If there is a firewall between you and name servers you want
     * to talk to, you might need to uncomment the query-source
     * directive below.  Previous versions of BIND always asked
     * questions using port 53, but BIND 8.1 uses an unprivileged
     * port by default.
     */
    // query-source address * port 53;

    /*
     * If running in a sandbox, you may have to specify a different
     * location for the dumpfile.
     */
    // dump-file "s/named_dump.db";
};

// Note: the following will be supported in a future release.
/*
host { any; } {
    topology {
        127.0.0.0/8;
    };
};
*/

// Setting up secondaries is way easier and the rough picture for this
// is explained below.
//
// If you enable a local name server, don't forget to enter 127.0.0.1
// into your /etc/resolv.conf so this server will be queried first.
// Also, make sure to enable it in /etc/rc.conf.

zone "." {
    type hint;
    file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
    type master;
    file "localhost.rev";
};

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example secondary config entries.  It can be convenient to become
// a secondary at least for the zone where your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// primary.
//
// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
// (This is the first bytes of the respective IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended.)
//
// Before starting to setup a primary zone, better make sure you fully
// understand how DNS and BIND works, however.  There are sometimes
// unobvious pitfalls.  Setting up a secondary is comparably simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.
//
// NOTE!!! FreeBSD runs BIND in a sandbox (see named_flags in rc.conf).
// The directory containing the secondary zones must be write accessible
// to BIND.  The following sequence is suggested:
//
//      mkdir /etc/namedb/s
//      chown bind:bind /etc/namedb/s
//      chmod 750 /etc/namedb/s

/*
zone "example.com" {
    type slave;
    file "s/example.com.bak";
    masters {
        192.168.1.1;
    };
};

zone "0.168.192.in-addr.arpa" {
    type slave;
    file "s/0.168.192.in-addr.arpa.bak";
    masters {
        192.168.1.1;
    };
};
*/

zone "example.org" {
    type master;
    file "example.org";
};

zone "example.org" {
    type slave;
    file "example.org";
};

$TTL 3600

example.org. IN SOA ns1.example.org. admin.example.org. (
            5          ; Serial
            10800      ; Refresh
            3600        ; Retry
            604800    ; Expire
            86400 )  ; Minimum TTL

; DNS Servers
@       IN NS      ns1.example.org.
@       IN NS      ns2.example.org.

; Machine Names
localhost       IN A    127.0.0.1
ns1      IN A    3.2.1.2
ns2      IN A    3.2.1.3
mail        IN A    3.2.1.10
@          IN A    3.2.1.30

; Aliases
www      IN CNAME   @

; MX Record
@          IN MX   10      mail.example.org.

recordname      IN recordtype  value

example.org. IN SOA ns1.example.org. admin.example.org. (
            5          ; Serial
            10800      ; Refresh after 3 hours
            3600        ; Retry after 1 hour
            604800    ; Expire after 1 week
            86400 )  ; Minimum TTL of 1 day

@       IN NS     ns1.example.org.

localhost       IN A    127.0.0.1
ns1      IN A    3.2.1.2
ns2      IN A    3.2.1.3
mail        IN A    3.2.1.10
@          IN A    3.2.1.30

www         IN CNAME   @

@         IN MX   10      mail.example.org.

$TTL 3600

1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
            5          ; Serial
            10800      ; Refresh
            3600        ; Retry
            604800    ; Expire
            3600 )    ; Minimum

@       IN NS   ns1.example.org.
@       IN NS   ns2.example.org.

2       IN PTR  ns1.example.org.
3       IN PTR  ns2.example.org.
10      IN PTR  mail.example.org.
30      IN PTR  example.org.

25.6.7. Кэширующий сервер имён

Кэширующий сервер имён - это сервер имён, не отвечающий ни за какую зону. Он просто выполняет запросы от своего имени и сохраняет результаты для последующего использования. Для настройки такого сервера достаточно исключить все описания зон из стандартной конфигурации сервера имён.

25.6.8. Запуск named в песочнице

Для дополнительной безопасности вам может потребоваться запускать named(8) с правами непривилегированного пользователя и настроить его на выполнение chroot(8) в каталог-песочницу. Это позволит сделать недоступным для даемона named все, что расположено вне песочницы. Если named будет взломан, то это поможет уменьшить возможный ущерб. По умолчанию во FreeBSD имеются пользователь и группа с именами bind, которые предназначены именно для такого использования.

Так как named не сможет обратиться ни к чему вне песочницы (например, совместно используемым библиотекам, сокетам протоколов и так далее), то нужно выполнить несколько шагов, чтобы named смог работать нормально. В следующем списке предполагается, что каталогом песочницы является /etc/namedb и что вы не делали никаких изменений в содержимом этого каталога. Выполните следующие шаги, работая как пользователь root:

• Создайте все каталоги, которые ожидает увидеть named:

  # cd /etc/namedb
  # mkdir -p bin dev etc var/tmp var/run master slave
  # chown bind:bind slave var/*
  

  

  Программе named нужен доступ с правом записи в эти каталоги, так что это все, что мы ей предоставим.

• Измените и создайте базовые файлы зоны и настроек:

  # cp /etc/localtime etc
  # mv named.conf etc && ln -sf etc/named.conf
  # mv named.root master
  # sh make-localhost
  # cat > master/named.localhost
  $ORIGIN localhost.
  $TTL 6h
  @   IN  SOA localhost. postmaster.localhost. (
              1   ; serial
              3600    ; refresh
              1800    ; retry
              604800  ; expiration
              3600 )  ; minimum
      IN  NS  localhost.
      IN  A       127.0.0.1
  ^D
  

  

  Это позволит программе named протоколировать правильное время в syslogd(8).

• Если вы используете FreeBSD версии ранее 4.9-RELEASE, то постройте статически скомпонованную копию named-xfer и скопируйте её в песочницу:

  # cd /usr/src/lib/libisc
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/lib/libbind
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/libexec/named-xfer
  # make cleandir && make cleandir && make depend && make NOSHARED=yes all
  # cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer
  

  После установки статически скомпонованного named-xfer, во избежание появления старых копий библиотек и программ в дереве исходного кода, требуется некоторая зачистка:

  # cd /usr/src/lib/libisc
  # make cleandir
  # cd /usr/src/lib/libbind
  # make cleandir
  # cd /usr/src/libexec/named-xfer
  # make cleandir
  

  

  Иногда при выполнении этого шага возникают ошибки. Если это случилось, выполните такую команду:

  # cd /usr/src && make cleandir && make cleandir
  

  и удалите ваше дерево /usr/obj:

  # rm -fr /usr/obj && mkdir /usr/obj
  

  При этом из вашего дерева исходных текстов будет удалён весь ''мусор'', и повторение вышеописанных шагов должно выполниться успешно.

  Если вы используете FreeBSD 4.9-RELEASE или более позднюю версию, то копия named-xfer в каталоге /usr/libexec по умолчанию является статически скомпонованной, и вы можете просто скопировать её в песочницу при помощи команды cp(1).

• Создайте файл устройства dev/null, который named может видеть и писать в него:

  # cd /etc/namedb/dev && mknod null c 2 2
  # chmod 666 null
  

• Создайте символическую ссылку /var/run/ndc на /etc/namedb/var/run/ndc:

  # ln -sf /etc/namedb/var/run/ndc /var/run/ndc
  

  Замечание: Это просто для того, чтобы не задавать опцию -c при каждом запуске ndc(8). Так как содержимое каталога /var/run удаляется при загрузке, может быть полезно добавить эту команду в crontab(5) для root с использованием параметра @reboot.

• Настройте syslogd(8) на создание дополнительного протоколирующего сокета log, в который может писать named. Для этого добавьте -l /etc/namedb/dev/log к переменной syslogd_flags из файла /etc/rc.conf.

• Задайте запуск named и выполнение chroot в песочницу, добавив следующее в /etc/rc.conf:

  named_enable="YES"
  named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"
  

  Замечание: Заметьте, что конфигурационный файл /etc/named.conf именуется по полному имени относительно песочницы, то есть в вышеприведённой строке указывается файл, который на самом деле является файлом /etc/namedb/etc/named.conf.

Следующим шагом является редактирование файла /etc/namedb/etc/named.conf так, чтобы named знал, какую зону загружать и где найти их на диске. Далее следует прокомментированный пример (все, что специально не прокомментировано, ничем не отличается от настройки сервера DNS, работающего не в песочнице):

options {
    directory "/";
    named-xfer "/bin/named-xfer";
    version "";     // Не выдавайте версию BIND
    query-source address * port 53;
};
// управляющий сокет ndc
controls {
    unix "/var/run/ndc" perm 0600 owner 0 group 0;
};
// Далее следуют зоны:
zone "localhost" IN {
    type master;
    file "master/named.localhost";
    allow-transfer { localhost; };
    notify no;
};
zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "master/localhost.rev";
    allow-transfer { localhost; };
    notify no;
};
zone "." IN {
    type hint;
    file "master/named.root";
};
zone "private.example.net" in {
    type master;
    file "master/private.example.net.db";
    allow-transfer { 192.168.10.0/24; };
};
zone "10.168.192.in-addr.arpa" in {
    type slave;
    masters { 192.168.10.2; };
    file "slave/192.168.10.db";
};

После выполнения шагов выше либо перезагрузите ваш сервер, либо перезапустите syslogd(8) и запустите named(8), не забыв использовать новые опции, заданные в syslogd_flags и named_flags. Теперь named должен заработать в песочнице!

25.6.9. Безопасность

Хотя BIND является самой распространенной реализацией DNS, всегда стоит вопрос об обеспечении безопасности. Время от времени обнаруживаются возможные и реальные бреши в безопасности.

Весьма полезно прочесть сообщения безопасности CERT и подписаться на Список рассылки FreeBSD, посвящённый срочным сообщениям, связанным с безопасностью для того, чтобы быть в курсе текущих проблем с обеспечением безопасности Internet и FreeBSD.

25.6.10. Дополнительная литература

Справочная информация по BIND/named: ndc(8), named(8) и named.conf(5)

• Официальная страница ISC BIND

• FAQ по BIND

• Книга издательства O'Reilly DNS and BIND 4th Edition

• RFC1034 - Domain Names - Concepts and Facilities

• RFC1035 - Domain Names - Implementation and Specification