О службе DNS (bind)

Если локальная сеть не подключена к сети Интернет, вполне возможно, что внутренний DNS-сервер в ней не нужен. За преобразование доменного имени в IP-адрес и обратно в Linux отвечает несколько разных механизмов, лишь один из которых базируется на службе доменных имён. В самом простом случае имена всех компьютеров вместе с их адресами можно записать в файл /etc/hosts. Порядок просмотра различных пространств имён указывается в файле /etc/nsswitch.conf. Строка hosts: files nisplus nis dns этого файла предписывает приложениям, пользующимся стандартной функцией gethostbyname() сначала заглянуть в /etc/hosts, затем попытаться получить таблицы hosts службы nisplus или nis, а только затем обращаться к DNS-серверу. Это вполне разумное правило, учитывая время выполнения запроса в каждом случае.

Если задачу преобразования имён в адреса взял на себя провайдер, собственный DNS-сервер можно тоже не заводить. В этом случае на всех компьютерах в качестве сервера имён указывается сервер провайдера (поле nameserver в файле /etc/resolv.conf), к которому и идут все запросы. Даже если внутренняя сеть организована согласно RFC1918 (интранет) и адреса компьютеров в ней не могут отображаться в сети Интернет, DNS-запросы во внешний мир работать будут. Между собой компьютерам предлагается общаться с помощью /etc/hosts или IP-адресов. 

Однако уже здесь очевидны две задачи, для решения которых можно организовать собственную службу доменных имён.

Первая задача - уменьшение времени ответа на DNS-запрос абонентов внутренней сети. Если канал подключения к Интернет обладает большим временем задержки (скажем, четверть секунды), то работа с данными, включающими в себя много доменных имён (например, с www-страницами) может стать весьма медленной, хотя общий объём трафика будет невелик. Система доменных имён - распределённая база данных, замечательно поддерживающая механизм кеширования запросов. Первое обращение к кеширующему DNS-серверу приводит к выполнению рекурсивного запроса: опрашивается сервер более высокого уровня, который, если не знает ответа, передаст запрос дальше. Результат запроса оседает в кеше, так что все последующие обращения именно к этой записи дальше кеширующего сервера не уйдут. Время жизни (Time To Live, TTL) записи в кеше определяется хозяином запрошенного доменного имени. По истечении TTL запись из кеша удаляется.

Вторая задача - именование компьютеров в интранет-сети. Это бывает важно, если среди компьютеров внутренней сети есть свои серверы (например, корпоративный WWW-сервер), к которым другие компьютеры обращаются по доменному имени. Поскольку адреса такой сети не пойдут дальше межсетевого экрана, вы можете использовать имя какого угодно, — в том числе несуществующего — домена и составить табличку в /etc/hosts. Однако раздавать эту табличку лучше всё-таки средствами DNS.

Обе эти задачи можно решить, воспользовавшись Bind - мощным полнофункциональным DNS-сервером (обратите внимание, пакет и сервис называются bind, а сама служба - named). При необходимости запуска bind с использованием chroot необходимо установить пакет bind-chroot. В этом случае будет использоваться каталог /var/named/chroot/.

Для того, чтобы запустить named в кеширующем режиме, достаточно раскомментировать и заполнить раздел настройки forwarders (вышестоящие серверы) в файле /var/named/chroot/etc/named.conf. Обратите внимание на возможные ограничения на право обращаться к серверу с обычными и рекурсивными запросами (настройки allow-query и allow-recursion). Можно раскомментировать находящиеся в этом файле разумные установки по умолчанию. Эти настройки открывают доступ только абонентам локальных сетей, т.е. сетей, к которым компьютер подключён непосредственно.

grep allow- /var/named/chroot/etc/named.conf
        allow-query     { localhost; any; };
        allow-query-cache { localhost; any; };

Использование Bind для полноценного именования компьютеров в локальной сети требует создания двух зон (т.е. прямой и обратной), содержащих в виде записей определённого формата информацию о доменных именах компьютеров и об их роли в этих доменах. Каждая зона должна включать запись типа SOA (State Of Authority, сведения об ответственности). В этой записи определяются основные временные и административные параметры домена, в том числе электронный адрес лица, ответственного за домен (администратора) и серийный номер зоны. Серийный номер - число в диапазоне от 0 до 4294967295 (2**32); каждое изменение, вносимое в зону, должно сопровождаться увеличением этого номера. Обнаружив увеличение серийного номера, кеширующие и вторичные серверы признают все закешированные записи из этой зоны устаревшими. Структура номера может быть любой, лишь бы он постоянно увеличивался. Удобно использовать формат «<год><месяц><число><версия>», где все числа, кроме года, двузначные, а версия может обнуляться раз в день, соответствовать времени (например, по формуле 100*(часы*60+минуты)/(60*24) или иметь сквозную нумерацию (в этом случае появляется сложность с переходом от версии 99 к версии 100, то есть 0). Даже если серийный номер генерируется автоматически, рекомендуется пользоваться этим форматом, наглядно отражающим время создания зоны. Пример зоны, не содержащей ничего, кроме записи SOA и обязательной записи типа NS, находится в файле /usr/share/doc/bind/sample/var/named/named.localhost.

Кроме записи типа SOA, в каждой зоне должна быть хотя бы одна запись типа NS (Name Server), указывающая адрес DNS-сервера, авторитетного в этом домене (как минимум - адрес сервера, на котором запущен named). Несколько зон включаются в настройку Bind автоматически (файл /var/named/chroot/etc/named.rfc1912.zones). Они нужны для обслуживания сети, привязанной к сетевой заглушке (127.0.0.1/8). Стоит обратить внимание на то, что имя домена, который обслуживается зоной, задаётся в файле настроек, а в самом файле зоны можно использовать относительную адресацию (без . в конце имени), так что операция переименования домена делается редактированием одной строки. Рекомендуется добавлять описания зон в конфигурационный файл /var/named/chroot/etc/named.rfc1912.zones.

Прямая зона нужна для преобразования доменного имени в IP-адрес - операции, необходимой многим программам постоянно. Большинство записей в прямой зоне - типа A (Address) - предназначены именно для этого. Другие часто встречающиеся типы записей - это CNAME (Canonical Name, настоящее имя), позволяющий привязать несколько дополнительных имён к одному, и MX (Mail eXchange, обмен почтой), указывающий, куда пересылать почтовые сообщения, в поле адресат которых встречается определённое доменное имя. Вот пример прямой зоны для воображаемого домена internal.domain.net (незначащие поля соответствующих файлов заменены на . . .):

# cat /var/named/chroot/etc/named.rfc1912.zones
 . . .
zone "example" IN {
        type master;
        file "internal.domain.net";
        allow-update { none; };
};
 . . .
# cat /var/named/chroot/var/named/internal.domain.net
$TTL    1D
@      IN     SOA server root.server (
2004082202      ; serial
12H             ; refresh
1H              ; retry
1W              ; expire
1H              ; ncache
                        )
IN     NS    server
MX 10   server
Server        A       10.10.10.1
www           CNAME   server
mail            CNAME   server
jack            A       10.10.10.100

В этом примере совпадение имени файла и имени зоны осмысленно - так проще разбираться с содержимым каталога /var/named/chroot/var/named/. Используются правила умолчания: если в записи некоторое поле опущено, оно наследуется от предыдущей. Так, вместо A можно было бы всюду написать IN A, а вместо MX - @ IN MX (@ означает имя домена, указанное в конфигурационном файле). Как видно из пример, всю работу в сети делает компьютер с адресом 10.10.10.1, он же server.internal.domain.net, он же www.internal.domain.net и mail.internal.domain.net. Несмотря на наличие среди CNAME этого сервера имени mail, MX-запись указывает всё же не на него, а на действительный адрес - так рекомендовано RFC. Распространённая практика заводить запись типа A непосредственно на имя зоны (т. е. присваивать адрес имени internal.domain.net) приводит, помимо незначительных выгод, к мелким, неочевидным и весьма трудно преодолимым трудностям, которые мы здесь описывать не будем, ограничившись советом не использовать этот - пусть и законный - трюк.

Для того чтобы преобразовывать IP-адреса в доменные имена, у каждой сети должна быть обратная зона. Если такой зоны нет, и в файле /etc/hosts тоже ничего не написано, операция не выполнится. Такое преобразование нужно гораздо реже и в основном по соображениям административным: для того, чтобы выяснить принадлежность компьютера (с которого, допустим, пытаются атаковать сервер) по его IP-адресу. Некоторые почтовые серверы проверяют, содержится ли IP-адрес машины, передающей сообщение, в обратной зоне и похоже ли полученное доменное имя на то, что указано в сообщении, и при несовпадении отказываются принимать письмо. К сожалению, поскольку неудобства, связанные с отсутствием обратной зоны, понятны лишь грамотному администратору, а таковых на просторах Интернета не слишком много, обратные зоны во множестве сетей либо отсутствуют, либо дают неверную информацию. В случае внутренней сети обратная зона необязательна, но желательна - для простоты администрирования и удовлетворения потребностей разных программных продуктов, которые ею пользуются.

Обратная зона состоит почти целиком из записей типа PTR (Pointer, указатель). Чтобы не умножать сущностей, решено было не вводить новый способ работы сервера имён и представить обратное преобразование IP-адреса как прямое преобразование доменного имени специального вида. Например, чтобы выяснить доменное имя компьютера с адресом 1.2.3.4, необходимо запросить информацию о доменном имени 4.3.2.1.in-addr.arpa. Таким образом, каждой подсети класса C (или выше) соответствует определённый домен, в котором можно найти ответ. Вот как выглядит обратная зона для нашего воображаемого домена:

 cat /var/named/chroot/etc/named.rfc1912.zones
zone "12.11.10.in-addr.arpa" { type master;
file "12.11.10.in-addr.arpa";
};
 cat /var/named/chroot/var/named/12.11.10.in-addr.arpa
$TTL 1D
@      IN     SOA  server.internal.domain.net.       root.server.internal.domain.net (
2004082201    ; serial
12H           ; refresh
1H            ; retry
1W            ; expire
1H            ; ncache
)
       IN     NS   server.internal.domain.net
0             PTR  internal.domain.net.
1             PTR  server.internal.domain.net
100           PTR  jack.internal.domain.net.

Обратите внимание, что относительные адреса, использованные в левой части записей PTR, раскрываются в полные вида <адрес>.12.11.10.in-addr.arpa, а в правой части используются полные (которые вполне могут указывать на имена в разных доменах).

Проверить синтаксическую правильность конфигурационного файла и файла зоны можно с помощью утилит named-checkconf и named-checkzone, входящих в пакет bind. Они же используются при запуске службы командой service bind start. Однако при интенсивной эксплуатации сервера, когда остановка службы нежелательна, можно попросить службу перечитать файлы настроек или определённые зоны с помощью утилиты rndc - вот тогда не стоит забывать о проверке синтаксиса.

Стоит иметь в виду, что, в отличие от прямых зон, обратные описывают административную принадлежность компьютеров, но сами принадлежат хозяину сети (как правило, провайдеру). Возникает особого рода затруднение, связанное с работой DNS-сервера уже не во внутренней сети, а в сети Интернет. Дело в том, что подсети класса C (т. н. сети /24, в которых сетевая маска занимает 24 бита, а адрес компьютера - 8) выдаются только организациям, способным такую подсеть освоить (в сети класса C 254 абонентских IP-адреса, один адрес сети и один широковещательный адрес). Чаще всего выдаются совсем маленькие подсети - от /30 (на два абонентских адреса) до /27 (на 30 адресов) - или другие диапазоны, сетевая маска которых не выровнена по границе байта. Таких подсетей в обратной зоне получится несколько, а возможности просто разделить её, отдав часть адресов в администрирование хозяевам, нет. Грамотный провайдер в таких случаях пользуется RFC2317 (есть в пакете bind-docs), предписывающем в обратной зоне заводить не записи вида PTR, а ссылки CNAME на адреса в «классифицированных» обратных зонах специального вида. Обратное преобразование становится двухступенчатым, зато администрирование каждой классифицированной зоны можно отдать хозяину.

DNS-сервер, отвечающий на запросы из сети Интернет, должен быть зарегистрирован в родительском домене. В самом деле, единственный способ узнать, кто обслуживает домен internal.domain.net - спросить об этом у DNS-сервера домена domain.net. Так что о выделении поддомена необходимо договариваться с провайдером. Регистрацией в доменах первого уровня занимаются выделенные организации. Например, домен в зоне .ru необходимо регистрировать в компании АНО «Региональный Сетевой Информационный Центр» (RU-CENTER).

Правила требуют, чтобы при регистрации домена было указано не менее двух DNS-серверов, которые будут его обслуживать. Из всех зарегистрированных серверов (записей типа NS в родительской зоне) только одна соответствует т.н. первичному (master) серверу, а остальные - т.н. вторичным (slave). Для внешнего пользователя вторичный сервер не отличается от первичного: он столь же авторитетен в ответе на запрос об именах его домена. Отличия только в способе администрирования. Все изменения вносятся в зоны первичного сервера, а вторичный только кеширует эти зоны, целиком получая их по специальному межсерверному протоколу. Полученная зона складывается в файл, редактировать который бессмысленно: первичный сервер при изменении зоны рассылает всем своим вторичным указание скачать её заново. Право на скачивание зоны можно ограничить настройкой allow-transfer (как правило, в ней перечисляются адреса вторичных серверов). Вот слегка отредактированная цитата из руководства по Bind, описывающая задание вторичного сервера в файле настроек:

// We are a slave server for eng.example.com
zone "eng.example.com" { type slave;
file "slave/eng.example.com";
// IP address of eng.example.com master server masters { 192.168.4.12; };
};

Вторичный сервер хорошо размещать где-нибудь подальше от первичного, во всяком случае, в другой сети - так повышается надёжность обработки запроса (если один сервер недоступен, возможно, ответит второй) и возрастает скорость распространения записей по кешам промежуточных серверов.

Проверку работоспособности, доступности и вообще самочувствия DNS-сервера лучше всего делать утилитой dig из пакета bind-utils. Это очень мощная утилита, выдающая максимум информации о том, что происходило с запросом (запрашивая обратное преобразование, не забудьте добавить ключ -x). Более лаконична, но не менее мощна утилита host из того же пакета. Упоминаемую старыми руководствами по UNIX утилиту nslookup использовать не рекомендуется.

# dig jack.internal.domain.net
<<>> DiG 9.2.4rc5 <<>> jack.internal.domain.net
;; global options:   printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32751
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;jack.internal.domain.net.        IN     A
;; ANSWER SECTION:
jack.internal.domain.net. 86400   IN     A       10.11.12.100
;; AUTHORITY SECTION:
internal.domain.net. 86400        IN     NS      server.internal.domain.net.
;; ADDITIONAL SECTION:
server.internal.domain.net. 86400 IN     A       10.11.12.1
;; Query time: 37 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Aug 22 16:07:17 2004 ;; MSG SIZE rcvd: 95

Наконец, для выяснения административной принадлежности тех или иных доменов и сетей можно воспользоваться утилитой whois, которая обращается к специальной сетевой базе данных (не имеющей отношения к DNS).

Дата последнего изменения: 03.09.2024

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.