Служба доменных имен (DNS) это сервис интернет, который ставит IP адреса и полностью квалифицированные доменные имена (FQDN) в соответствие одно другому. Поэтому DNS облегчает проблему запоминания IP адресов. Компьютеры, на которых запущен DNS , называются серверами имен (name servers). Ubuntu поставляется с BIND (сервис интернет имен Беркли), наиболее распространенную программу, используемую для управления серверами имен под Линукс.
5. Теперь перегружаем BIND9 для применения изменений:
Sudo service bind9 restart
Теперь вы можете увидеть файл /var/log/query.log, заполненный информацией о запросах. Это простейший пример использования опций журналирования BIND9.
Ссылки
Общие типы записей
Этот раздел покажет некоторые наиболее общие типы записей DNS .
1. A запись: Эта запись указывает IP адрес для сетевого имени (hostname).
Www IN A 192.168.1.12
2. CNAME запись: Используется для создания псевдонима (alias) на A запись. Вы не можете создавать CNAME запись, указывающую на другую CNAME запись.
Web IN CNAME www
3. MX запись: Используется для определения куда должна посылаться электронная почта (email). Должна указывать на A запись, не на CNAME .
IN MX 1 mail.example.com. mail IN A 192.168.1.13
4. NS запись: Используется для определения какие сервера поддерживают копии зоны. Должна указывать на A запись, не на CNAME . Ею определяются первичные и вторичные сервера зоны.
Сегодня мы поговорим о настройке, пожалуй, самого популярного DNS сервера bind9 . Следуйте инструкции, и у Вас всё получится, в этом нет ничего сложного. В этом примере Вы увидите как формируются файлы зон и проследите процесс простой настройки, не вдаваясь при этом в подробности. Это лишь небольшое HowTo , призванное помочь Вам понять принцип работы DNS сервера. Если же Вы настраиваете DNS сервер на шлюзе в сегменте Вашей локальной сети, то в конце статьи Вы увидите как сделать Ваш DNS сервер кэширующим , что позволит существенно сократить время повторного запроса к NS серверам, ведь посещённые адреса будут браться из Вашего локального кэша. Ну что ж, приступим.
Если у Вас ещё не установлен bind9, проделаем это:
Отредактируем файл /etc/init.d/sysklogd, он должен выглядеть следующим образом:
Теперь непосредственно создадим наш файл зоны сайт в той же папке /etc/bind:
1 | $ORIGIN сайт. |
Где 192.168.0.1 — IP Вашего сервера, MX запись нам нужна если Вы поднимаете на своем сервере почтовый сервер. ns1.сайт — наш DNS сервер. Так как для функционирования DNS сервера требуется помимо master ns сервер и slave , прописываем его — ns2.bla-bla-bla.com . Естественно у Вас он должен быть на стороннем сервере, либо если у Вас есть ещё выделенный IP для Вашего сервера, то задача упрощается. Для сервера, находящегося в локальной сети и выдающего имена только в локальную сеть (к примеру у Вас установлен web-сервер, обслуживающий Вашу сеть и настроены виртуальные хосты), достаточно лишь прописать ns1, т.е. адрес Вашего DNS сервера. 2008082859 — смените на текущую дату.
Выставим нужные права на файл зоны сайт :
chown bind:bind /etc/bind/сайт
Отредактируем файл конфигурации bind /etc/bind/named.conf, включив в него конфигурацию для наших зон, добавим в конец файла:
Ну и обновим конфигурацию bind командой:
Если у Вас DNS сервер установлен на шлюзе в Вашей локальной сети, сделаем его кэширующим. Открываем файл /etc/bind/named.conf.options и раскомментируем следующую строку:
forwarders { |
Добавим в неё IP адреса DNS серверов к которым будет обращаться наш сервер, с большой долей вероятности у Вашего провайдера есть свои DNS сервера, укажем их первыми, тем самым экономя трафик:
При настройке на slave сервере myzones.conf примет такой вид:
На этом всё, настройка закончена. ;) Удачи!
Существует много способов настроить BIND9. Наиболее распространенные конфигурации - это кэширующий сервер имен, первичный мастер и вторичный мастер.
Когда BIND9 настроен как кэширующий сервер, он ищет ответы на запросы имени и запоминает ответ на случай, если запрос придет повторно.
В качестве первичного мастера BIND9 читает данные зоны из локального файла и является ответственным за эту зону.
В качестве вторичного мастера BIND9 получает данные по зоне (целиком) с другого сервера имен, отвечающего за эту зону.
Обзор
Файлы настройки DNS сохраняются в каталоге /etc/bind. Основной файл конфигурации - это /etc/bind/named.conf.
Строки include определяют имена файлов, которые содержат DNS опции. Строка directory в файле /etc/bind/named.conf.options говорит DNS где искать файлы. Все файлы, используемые BIND, будут относительными к этому каталогу.
Файл с именем /etc/bind/db.root описывает корневые сервера имен в мире. Сервера со временем меняются, поэтому файл /etc/bind/db.root должен обслуживаться сейчас и потом. Обычно это происходит в качестве обновления к пакету bind9 . Секция zone определяет мастер сервер и она сохранена в файле, определяемой опцией file .
Существует возможность настроить один сервер как кэширующий сервер имен, первичный мастер и вторичный мастер одновременно. Сервер может быть началом авторизации (SOA) для одной зоны, при этом предоставляя вторичный сервис для другой. И при всем этом предоставлять кэширующий сервис в локальной сети (LAN).
Кэширующий сервер имен
По умолчанию конфигурация настраивается на работу кэширующим сервером. Все что для этого требуется - это добавить IP адреса DNS серверов вашего интернет провайдера. Просто раскомментируйте и исправьте следующее в /etc/bind/named.conf.options:
Forwarders { 1.2.3.4; 5.6.7.8; };
Замените 1.2.3.4 и 5.6.7.8 на актуальные IP адреса серверов имен.
Теперь перегружаем DNS сервер для применения новой конфигурации. Наберите в терминале:
Sudo service bind9 restart
Многие администраторы предпочитают использовать дату последнего редактирования в качестве Serial зоны в виде 2012010100, что соответствует формату yyyymmddss (где ss - Serial Number [за день]).
Как только вы произвели изменения в файле зоны, требуется перегрузить BIND9 для применения изменений:
Sudo service bind9 restart
Файл обратной зоны
Теперь, поскольку зона создана и разрешает имена в IP адреса, требуется создать также обратную зону. Обратная зона позволяет DNS определять имя по IP адресу.
Редактируем /etc/bind/named.conf.local и добавляем следующее:
Zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; };
Замените 1.168.192 на первые три октета адресов сети, которую вы используете. Также соответственно назовите файл зоны /etc/bind/db.192. В нем должен совпадать первый октет вашей сети.
Теперь создаем файл /etc/bind/db.192:
Sudo cp /etc/bind/db.127 /etc/bind/db.192
; ; BIND reverse data file for local 192.168.1.XXX net ; $TTL 604800 @ IN SOA ns.example.com. root.example.com. (2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800) ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR ns.example.com.
Serial Number в обратной зоне также требуется увеличивать при каждом изменении. Для каждой A записи, которую вы настроите в /etc/bind/db.example.com на другой адрес, вы должны создать запись PTR в /etc/bind/db.192.
После создания файла обратной зоны перегрузите BIND9:
Sudo service bind9 restart
Вторичный мастер
Поскольку первичный мастер настроен, требуется вторичный мастер для того, чтобы поддерживать домен при недоступности первичного мастера.
Для начала на первичном мастере надо разрешить передачу зоны. Добавьте опцию allow-transfer к определениям прямой и обратной зон в /etc/bind/named.conf.local:
Zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.11; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; allow-transfer { 192.168.1.11; }; };
Замените 192.168.1.11 на IP адрес вашего вторичного сервера имен.
Перезапустим BIND9 на первичном мастере:
Zone "example.com" { type slave; file "db.example.com"; masters { 192.168.1.10; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "db.192"; masters { 192.168.1.10; }; };
Замените 192.168.1.10 на IP адрес вашего первичного сервера имен.
Перегружаем BIND9 на вторичном мастере:
Sudo service bind9 restart
В /var/log/syslog вы сможете увидеть нечто похожее на (некоторые строки разделены для соответствия формату документа):
Client 192.168.1.10#39448: received notify for zone "1.168.192.in-addr.arpa" zone 1.168.192.in-addr.arpa/IN: Transfer started. transfer of "100.18.172.in-addr.arpa/IN" from 192.168.1.10#53: connected using 192.168.1.11#37531 zone 1.168.192.in-addr.arpa/IN: transferred serial 5 transfer of "100.18.172.in-addr.arpa/IN" from 192.168.1.10#53: Transfer completed: 1 messages, 6 records, 212 bytes, 0.002 secs (106000 bytes/sec) zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5) client 192.168.1.10#20329: received notify for zone "example.com" zone example.com/IN: Transfer started. transfer of "example.com/IN" from 192.168.1.10#53: connected using 192.168.1.11#38577 zone example.com/IN: transferred serial 5 transfer of "example.com/IN" from 192.168.1.10#53: Transfer completed: 1 messages, 8 records, 225 bytes, 0.002 secs (112500 bytes/sec)
Обратите внимание, что передача зоны произойдет только если Serial Number на первичном сервере больше значения на вторичном. Если вы хотите, чтобы первичный мастер DNS сообщал вторичному DNS серверу об изменении зоны, вы можете добавить also-notify { ipaddress; }; в /etc/bind/named.conf.local как показано в примере ниже: zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; }; };
Сегодня продолжим цикл статей по настройке сервера и рассмотрим что же из себя представляет настройка DNS сервера Ubuntu. У нас уже есть сервер на базе ubuntu 14.04.1 LTS, на нем настроен DHCP сервер. Сегодня мы туда добавим еще и службу DNS.
Для начала давайте разберемся для чего он нам нужен. DNS – это система доменных имен, предназначенная для получения ip адреса компьютера по его имени и наоборот, имени по ip адресу. Т.е. зная имя компьютера, вам не нужно запоминать его ip, для последующего обращения. Служба была создана в связи с расширением сети и появлением огромного множества ip адресов, которые просто невозможно запомнить с первого раза.
По многочисленным просьбам читателей, я еще раз перепроверил все пункты и нашел некоторые ньюансы из-за которых сервер некорректно работал (изначально статья была написана для ubuntu server 11.04). Статья полностью переписана и проверена на Ubuntu Server 14.04.1
