У страха глаза велики, и слабый мочевой пузырь.

Cтоит мужичёк, смотрит на диски (долго смотрит, ибо порядочно выпивший), потом выдаёт продавцу: ...

Второй кандидат в релизы инсталлятора Debian 10 "Buster"
Wed, 26 Jun 2019 23:08:37 +0300

Релиз JPype 0.7, библиотеки для доступа к Java-классам из Python
Wed, 26 Jun 2019 22:46:07 +0300

Релиз Chrome OS 75
Wed, 26 Jun 2019 19:50:38 +0300

Разработчики из Google предложили разработать свою libc для LLVM
Wed, 26 Jun 2019 12:36:50 +0300

Уязвимость в AMD SEV, позволяющая определить ключи шифрования
Wed, 26 Jun 2019 10:21:13 +0300

Выпуск nginx 1.17.1 и njs 0.3.3
Wed, 26 Jun 2019 08:50:32 +0300

Обновление Solaris 11.4 SRU 10
Wed, 26 Jun 2019 02:28:47 +0300

Выпуск пакетного фильтра nftables 0.9.1
Tue, 25 Jun 2019 23:20:26 +0300

Совет директоров Apache Software Foundation покинули три видных участника
Tue, 25 Jun 2019 21:08:22 +0300

Доступна бета-версия Linux-редакции игрового движка OpenXRay
Tue, 25 Jun 2019 17:35:02 +0300

Выпуск PyOxidizer для упаковки Python-проектов в самодостаточные исполняемые файлы
Tue, 25 Jun 2019 12:52:38 +0300

Доступен дистрибутив SUSE Linux Enterprise 15 SP1
Tue, 25 Jun 2019 11:11:52 +0300

Утечка BGP-маршрутов привела к массовому нарушению связности в интернете
Tue, 25 Jun 2019 09:41:14 +0300

Представлена плата Raspberry Pi 4
Mon, 24 Jun 2019 23:24:16 +0300

Представлен people.kernel.org, сервис блогов для разработчиков ядра Linux
Mon, 24 Jun 2019 21:58:05 +0300

Canonical пересмотрела планы по прекращению поддержки архитектуры i386 в Ubuntu
Mon, 24 Jun 2019 21:07:39 +0300

Открыты исходные тексты языка программирования V
Mon, 24 Jun 2019 10:32:15 +0300

Поддержка 32-разрядных библиотек в Ubuntu 19.10+ будет заимствована из Ubuntu 18.04
Sun, 23 Jun 2019 22:07:09 +0300

Выпуск файлового менеджера Midnight Commander 4.8.23
Sun, 23 Jun 2019 21:15:58 +0300

В рамках проекта TinyWare подготовлена новая сборка Slackware
Sun, 23 Jun 2019 20:37:24 +0300

Выпуск GNU APL 1.8
Sun, 23 Jun 2019 20:29:05 +0300

Miсrosoft открыл код системы распределения памяти mimalloc
Sun, 23 Jun 2019 09:15:24 +0300

Инициатива для защиты Linux от патентных претензий преодолела отметку в 3000 участников
Sun, 23 Jun 2019 08:01:16 +0300

Выпуск libhandy 0.0.10, библиотеки для создания мобильных вариантов приложений GTK/GNOME
Sat, 22 Jun 2019 21:02:40 +0300

Valve отказывается от официальной поддержки Steam в Ubuntu 19.10+
Sat, 22 Jun 2019 17:35:07 +0300

Взлом внутренней сети NASA через плату Raspberry Pi
Sat, 22 Jun 2019 10:24:07 +0300

Выпуск Wine 4.11
Sat, 22 Jun 2019 09:00:28 +0300

В OpenSSH добавлена защита от атак по сторонним каналам
Sat, 22 Jun 2019 05:06:15 +0300

Проект VKHR развивает систему рендеринга волос в режиме реального времени
Fri, 21 Jun 2019 20:13:25 +0300

Для Firefox развивается режим блокировки виджетов социальных сетей и Firefox Proxy
Fri, 21 Jun 2019 11:50:12 +0300

Началась работа по переводу GNOME Mutter на многопоточную отрисовку
Fri, 21 Jun 2019 11:09:18 +0300

Открыт код Sorbet, системы статической проверки типов для Ruby
Fri, 21 Jun 2019 10:31:38 +0300

Прекращение поддержки i386 в Ubuntu приведёт к проблемам с поставкой Wine
Fri, 21 Jun 2019 09:02:12 +0300

Percona проведёт открытые семинары в Санкт-Петербурге, Ростове-на-Дону и Москве
Fri, 21 Jun 2019 03:56:43 +0300

Google открыл систему для анализа наборов данных без нарушения конфиденциальности
Thu, 20 Jun 2019 23:09:39 +0300

Обновление PostgreSQL 11.4, 10.9, 9.6.14, 9.5.18 и 9.4.23
Thu, 20 Jun 2019 21:57:10 +0300

В Firefox 67.0.4 и 60.7.2 устранена ещё одна 0-day уязвимость
Thu, 20 Jun 2019 20:53:38 +0300

Выпуск HTTP/TCP-балансировщика HAProxy 2.0
Thu, 20 Jun 2019 12:05:12 +0300

Обновление DNS-сервера BIND 9.14.3, 9.11.8, 9.15.1 с устранением DoS-уязвимости
Thu, 20 Jun 2019 10:02:28 +0300

Релиз минималистичного дистрибутива Alpine Linux 3.10
Thu, 20 Jun 2019 09:47:21 +0300

Web сервер Лицензия Apache DNS сервер SAMBA сервер настройки SAMBA
Сервер имен в Linux

Первый шаг в установке DNS-серверов для вашей организации преобразовать таблицу узлов в эквивалентные зональные данные. Поиск адреса для имени иногда называется прямым отображением, а поиск имени по адресу - обратным отображением. Каждая сеть имеет собственный файл с данными для обратного отображения.

Файл, содержащий данные преобразования имен хостов в адреса, мы назовем db.DOMAIN. Для домена myco.ru этот файл называется db.myco.ru. Соответственно, файлы, содержащие данные преобразования адресов в имена хостов, носят имена вида db.ADDR, где ADDR - номер сети без последних нулей или маски сети. В нашем примере файлы будут называться db.192.168.100 и db.192.168.200; по одному файлу на каждую сеть. Префикс db - это сокращение для базы данных (database). Этот набор файлов db.DOMAIN и db.ADDR мы будем называть файлами данных зоны. Существуют и другие файлы данных зоны: db.cache и db.127.0.0. Это своего рода нагрузка. Каждый DNS-сервер должен иметь такие файлы, и для каждого сервера они более или менее похожи.

Чтобы связать файлы данных зоны, DNS-серверу требуется файл настройки - в BIND версии 4 этот файл обычно называется /etc/na-med.boot. В BIND версий 8 и 9 файл обычно называется /etc/named.conf. Формат файлов данных зон одинаков во всех реализациях DNS, он называется форматом мастер-файла. Однако формат файлов настройки является специфичным для реализации DNS-сервера - в нашем случае для DNS-сервера BIND.

Большинство записей в файлах данных зоны называются RR-записями DNS. При поиске DNS не обращает внимания на регистр символов, так что имена в файлах данных зоны можно набирать в произвольном регистре, даже в смешанном. Мы практически всегда используем строчные буквы. Несмотря на то, что поиск нечувствителен к регистру символов, регистр сохраняется при возвращении результатов. Таким образом, если добавить к файлам данных зоны записи с именем Tools.myco.ru, результаты поиска для tools.myco.ru будут содержать эти записи, но с заглавной буквой «Т» в имени домена.

RR-записи должны начинаться с первой позиции строки. В RFC-документах по DNS RR-записи в примерах приводятся в определенном порядке. Многие люди следуют этому порядку (и мы не исключение), но такой порядок следования записей не является обязательным. Итак, выбранный порядок следования записей:

SOA-запись

Указывает на авторитативностъ для зоны

NS-запись

Перечисляет DNS-серверы зоны

Прочие записи

Данные об узлах зоны

Из прочих записей будут рассмотрены:

А

Отображение имен узлов в адреса

PTR

Отображение адресов в имена узлов

CNAME

Каноническое имя (для псевдонимов)

Файлы данных зоны легче читать, если они содержат комментарии и пустые строки. Комментарии начинаются с символа точки с запятой (;) и заканчиваются концом строки. Как вы, вероятно, догадались, DNS-сервер игнорирует комментарии и пустые строки.

Следующая часть (или первая - для DNS-серверов более старых, чем BIND версии 8.2) в каждом из наших файлов - SOA-запись (RR-запись типа SOA). SOA-запись показывает, что данный DNS-сервер является самым надежным источником информации в пределах этой зоны. Наш DNS-сервер является авторитативным для зоны myco.ru по при­чине наличия SOA-записи. SOA-запись должна присутствовать в каж­дом файле db.DOMAIN и dbADDR. В файле данных зоны может при­сутствовать одна и только одна SOA-запись.

Мы добавили следующую SOA-запись к файлу db.myco.ru:

myco.ru. IN SOA vova.myco.ru. fin.myco.ru. (
1     ; Порядковый номер
3h    ; Обновление через 3 часа
1h    ; Повторение попытки через 1 час
1w    ; Устаревание через 1 неделю
1h )  ; Отрицательное TTL в 1 час

Имя myco.ru. должно начинаться в первой позиции строки файла. Убедитесь, что имя заканчивается точкой, как в этом примере, иначе результат вас сильно удивит!

Буквы IN обозначают Internet. Это один из классов данных - существуют и другие, но ни один из них в настоящее время широко не применяется. В наших примерах встречается только класс IN. Класс можно не указывать. Если класс не указан, DNS-сервер определяет его по выражению, диктующему чтение файла данных в файле настройки; чуть позже мы рассмотрим и это выражение.

Первое имя после SOA (vova.myco.ru.) - это имя первичного мастер-сервера DNS зоны myco.ru. Второе имя (fin.myco.ru.) - это адрес электронной почты человека, управляющего зоной; чтобы использовать адрес, следует заменить первый символ «.» на символ «@». Часто можно увидеть имена root, postmaster или hostmaster в почтовых адресах. Серверы имен не пользуются этими адресами, поскольку они предназначены для использования людьми. Если возникла проблема, имеющая отношение к зоне, всегда можно отправить сообщение по указанному почтовому адресу. Версии BIND, начиная с 4.9, предоставляют для указания такого адреса специальный тип RR-записей, RP (responsible person, ответственное лицо).

Скобки позволяют растягивать SOA-запись на несколько строк. Большинство полей в SOA-записи используются вторичными DNS-серверами. Пока просто будем считать, что выбрали разумные значения полей.

Аналогичные SOA-записи мы добавляем в файлы db.192.168.100 и db.192.168.200. В этих файлах первое имя в SOA-записи изменяется с myco.ru. на имя соответствующей зоны in-addr.arpa: 100.168.192.iп-addr.arpa. и 200.168.192.in-addr.arpa.

Следующие части, которые мы добавляем к каждому из файлов, - это NS-записи (name server, DNS-сервер). По одной NS-записи на каждый DNS-сервер, который является авторитативным для нашей зоны. Вот NS-записи из файла db.myco.ru:

myco.ru. IN NS vova.myco.ru.
myco.ru. IN NS lin.myco.ru.

Эти записи указывают, что существует два DNS-сервера для зоны myco.ru(можно ограничиться и одним). Серверы запущены на узлах vova.myco.ru и lin.myco.ru. Хосты, входящие одновременно в несколько сетей, скажем, lin.myco.ru, идеально подходят на роли DNS-серверов, поскольку имеют «правильное подключение». Такой узел напрямую доступен узлам более чем одной сети, а если является маршрутизатором, то находится под пристальным наблюдением со стороны администратора.

Как и в случае с SOA-записью, NS-записи мы добавляем также к файлам db.192.168.100 и db.192.168.200.

Теперь мы создадим отображения имен в адреса путем добавления следующих RR-записей в файл db.myco.ru:

; Адреса узлов
localhost.myco.ru. IN A 127.0.0.1
fin.myco.ru. IN A 192.168.100.2
vova.myco.ru. IN A 192.168.100.3
diehard.myco.ru. IN A 192.168.100.4
misery.myco.ru. IN A 192.168.200.2
shining.myco.ru. IN A 192.168.200.3
carrie.myco.ru. IN A 192.168.200.4
; Жители нескольких сетей
lin.myco.ru. IN A 192.168.100.1
lin.myco.ru. IN A 192.168.200.1
; Псевдонимы
bigt.myco.ru. IN CNAME vova.myco.ru.
dh.myco.ru. IN CNAME diehard.myco.ru.
wh.myco.ru. IN CNAME lin.myco.ru.
wh100.myco.ru. IN A  192.168.100.1
wh200.myco.ru. IN A 192.168.200.1
           

Первые два блока записей вряд ли когото удивят. Буква А обозначает адрес, а каждая RR-запись определяет отображение имени в соответствующий адрес, lin.myco.ru является маршрутизатором. Этот узел имеет два адреса, привязанных к имени, а следовательно - и две адресные записи. В отличие от поиска по таблице узлов, поиск DNS может возвращать несколько адресов для имени; так, поиск адреса lin.myco.ru возвращает два результата. Если автор запроса и DNS-сервер расположены в одной сети, некоторые DNS-серверы в целях повышения эффективности сетевого обмена возвращают более «близкий» адрес первым. Эта возможность носит название сортировки адресов. Если сортировка адресов неприменима, адреса подвергаются круговой перестановке между запросами, так что в последующих ответах они перечисляются в отличающемся порядке. Эта круговая система («round robin») впервые появилась в BIND версии 4.9.

Третий блок содержит псевдонимы таблицы узлов. Для первых трех псевдонимов мы создали CNAME-RR-записи (canonical names, записи канонических имен). Однако для двух других псевдонимов мы создали адресные записи (почему - расскажем через несколько строк). CNAME-запись определяет отображение псевдонима в каноническое имя узла. Сервер имен работает с записями типа CNAME совершенно не так, как обычно происходит работа с псевдонимами из таблицы узлов. При поиске имени, если DNS-сервер находит CNAME-запись, то имя узла заменяется каноническим именем, после чего поиск продолжается уже для этого имени. К примеру, когда сервер обрабатывает запрос для имени wh.myco.ru, то находит CNAME-запись, которая указывает на lin.myco.ru. Сервер производит поиск lin.myco.ru и возвращает оба адреса.

Следует запомнить одну вещь, которая касается псевдонимов вроде bigt.myco.ru - они никогда не должны появляться в правой части RR-записей. Иначе говоря, в части данных RR-записи следует всегда использовать канонические имена (скажем, vova.myco.ru). Обратите внимание, что в свежесозданных NS-записях используются именно канонические имена.

Две последних записи призваны решить специфическую проблему. Предположим, что необходимо проверить работу одного из интерфейсов маршрутизатора, например, lin.myco.ru. Одним из часто применяемых способов диагностики является использование ping в целях проверки рабочего состояния интерфейса. Если попытаться использовать ping для имени lin.myco.ru, DNS-сервер вернет оба адреса узла, ping использует первый адрес из списка. Но какой адрес является первым?

Если бы речь шла о таблице узлов, мы бы выбирали между именами wh100.myco.ru и wh200.myco.ru; и каждому имени соответствовал бы единственный адрес этого узла. Чтобы получить эквивалентную возможность в DNS, не следует создавать псевдонимы (CNAME-запи-си) для wh100.myco.ru и wh200.myco.ru, т. к. это приведет к тому, что при поиске по псевдониму будут возвращаться оба адреса lin.myco.ru. Вместо этого следует использовать адресные записи. Таким образом, чтобы проверить работу интерфейса 192.168.200.1 на узле lin.myco.ru, мы выполняем команду ping wh200.myco.ru, поскольку это имя соответствует единственному адресу. То же справедливо и для wh100.myco.ru. (хотя вместо этого можно выполнить ping 192.168.200.1 и не применять эти записи в файле db.myco.ru вообще).

Сформулируем основное правило: если узел имеет интерфейсы с более чем одной сетью, следует создать по одной адресной (А) записи для каждого уникального псевдонима адреса. CNAME-записи служат для создания псевдонимов, являющихся общими для всех адресов.

При этом не стоит рассказывать пользователям об именах wh100.myco.ru и wh200.myco.ru. Эти имена предназначены только для служебного использования. Если пользователи привыкнут использовать имена вроде wh100.myco.ru, у них возникнут проблемы, поскольку это имя будет работать не во всех контекстах (скажем, не будет работать для файлов .rhosts). Происходить это будет потому, что в некоторых контекстах требуется имя, которое является результатом поиска по адресу, то есть каноническое имя lin.myco.ru.

Мы использовали адресные (А) записи для создания псевдонимов wh100.myco.ru и wh200.myco.ru, и может возникнуть вопрос: «Можно ли использовать адресные записи вместо CNAME-записей во всех случаях?». У большинства приложений использование адресных записей вместо CNAME-записей затруднений не вызывает, поскольку их интересует только соответствующий IP-адрес. Но есть одно приложение, а именно, sendmail, поведение которого изменяется. Sendmail обычно заменяет псевдонимы в заголовках почтовых сообщений соответствующими каноническими именами; и канонизация происходит только в том случае, если для имен, указанных в заголовке, существуют CNAME-данные. Если не использовать CNAME-записи для создания псевдонимов, приложению sendmail придется рассказать обо всех возможных псевдонимах, под которыми может быть известен узел, а это потребует дополнительных усилий по настройке sendmail.

Помимо проблем sendmail, проблемы могут возникать и у пользователей, которым понадобится выяснить каноническое имя узла для записи его в файл .rhosts. Поиск по псевдониму, для которого существует CNAME-запись, вернет каноническое имя, но если существует только адресная запись, этого не произойдет. В таком случае пользователям для получения канонического имени придется производить поиск по IP-адресу, как это делает программа rlogind, но такие умные пользователи никогда не встречаются в системах, которые мы администрируем :).

Теперь мы создадим отображения адресов в имена. Файл db.192.168.100 содержит отображения адресов в имена узлов для сети 192.168.100/24. Для такого отображения используются RR-записи DNS, которые носят название PTR-записей или записей-указателей (pointer records). Для каждого сетевого интерфейса хоста присутствует ровно одна запись. (Вспомним, что поиск по адресам в DNS - это, по сути дела, поиск по именам. Адрес инвертируется и к нему добавляется имя in-addr.arpa.)

Вот PTR-записи, которые мы добавили для сети 192.168.100/24:

1.249.249.192.in-addr.агра.      IN   PTR lin.myco.ru.
2.249.249.192.in-addr.arpa.      IN   PTR fin.myco.ru.
3.249.249.192.in-addr.агра.      IN   PTR vova.myco.ru.
4.249.249.192.in-addr.arpa.      IN   PTR al.myco.ru.

Здесь есть пара моментов, на которые стоит обратить внимание. Во-первых, каждый адрес должен указывать на единственное имя - каноническое. Так, адрес 192.168.100.1 отображается в lin.myco.ru, но не в wh100.myco.ru. Допускается создание двух PTR-записей, одной для lin.myco.ru и одной для wh100.mo-vie.edu, но большинство систем не приспособлены для того, чтобы увидеть более одного имени, соответствующего адресу. Во-вторых, несмотря на то, что узел lin.myco.ru имеет два адреса, здесь указан только один из них. Это происходит потому, что файл отображает только прямые соединения с сетью 192.168.100/24, и узел lin.myco.ru имеет только одно такое соединение.

Аналогичные данные мы создаем для сети 192.168.200/24.

Loopback-адрес

Серверу имен требуется еще один дополнительный файл dbADDR для lоорbаск-сети и специального адреса, который используется хостом для направления пакетов самому себе. Эта сеть (почти) всегда имеет номер 127.0.0/24, а адрес узла (почти) всегда 127.0.0.1. Следовательно, файл имеет имя db.127.0.0. Что неудивительно, поскольку он похож на другие файлы dbADDR.

Вот содержимое файла db.127.0.0:

$TTL 3h
0.0.127.in-addr.arpa. IN SOA vova.myco.ru. fin.myco.ru. (
1                 ;    Порядковый номер
3h                ;    Обновление через 3 часа
1h                ;    Повторение попытки через 1 час
1w                ;    Устаревание через 1 неделю
1h   )   ;    Отрицательное TTL в 1 час

0.0.127.in-addr.агра. IN NS vova.myco.ru.
0.0.127.in-addr.агра. IN NS lin.myco.ru.
1.0.0.127.in-addr.arpa. IN PTR localhost.

Зачем DNS-серверам нужен этот глупый маленький файл? Задумаемся на секунду. Никто не отвечает за сеть 127.0.0/24, но она используется многими системами в качестве loopback. Поскольку никто не отвечает за эту сеть, каждый отвечает за нее самостоятельно. Можно обойтись без этого файла, и DNS-сервер будет работать. Однако поиск по адресу 127.0.0.1 не даст положительных результатов, поскольку корневой DNS-сервер не был настроен таким образом, чтобы отображать адрес 127.0.0.1 в конкретное имя. Чтобы избежать сюрпризов, это отображение должен обеспечить администратор DNS-сервера.

Создание файла настройки BIND

Наконец, создав файлы данных для зоны, мы должны объяснить DNS-серверу, какие именно файлы следует использовать. В BIND для этой цели применяется механизм файла настройки. До сих пор мы обсуждали файлы, формат которых определяется спецификациями DNS. Файл настройки является уникальным для BIND, и его формат не определен RFC-документами по DNS.

Синтаксис файла настройки существенно изменился при переходе от версий 4 к версиям 8. К счастью, он не изменился при переходе от версии 8 к версии 9. Мы начнем с синтаксиса для BIND 4, а затем опишем эквивалентные конструкции для BIND 8 и 9. Сверьтесь со страницами руководства по named и уточните, какую версию синтаксиса следует использовать. Если у вас уже есть файл настройки для BIND 4, его можно преобразовать в формат BIND 8 или 9, выполнив программу паmed-bootconf, которая входит в комплект поставки исходных текстов BIND. В BIND 8 эта программа находится в каталоге src/bin/named-bootconf. В BIND 9 - в каталоге contrib/named-bootconf. (а проще найти ее так: locate named-bootconf, если пакет BIND был установлен недавно, незабудьте выполнить updatedb перед использованием locate)

В BIND версии 4, комментарии в файле настройки выглядят так же, как и в файлах данных зоны, они начинаются с символа точки с запятой и заканчиваются концом строки:

;  это комментарий

В BIND 8 и 9 можно пользоваться одним из трех стилей комментариев: С-стилем, C++ -стилем или стилем командного интерпретатора:

/* Комментарий в стиле языка С */

// Комментарий в стиле языка C++

# Комментарий в стиле командного интерпретатора

Не пользуйтесь комментариями в стиле BIND 4 в файлах настройки для BIND 8 и 9 - работать это не будет, потому что в последних версиях BIND точка с запятой является признаком конца оператора настройки.

Обычно файлы настройки содержат строку, определяющую каталог, в котором расположены файлы данных зоны. Сервер имен изменяет рабочий каталог на указанный перед чтением файлов данных зоны, что позволяет указывать имена файлов относительно текущего каталога. Вот так выглядит указание каталога для BIND 4:

directory /var/named

А так - для BIND 8 и 9:

options {
directory "/var/named";
// здесь указываются дополнительные параметры

};

В файле настройки может присутствовать только один оператор options, так что любые дополнительные параметры, упомянутые далее по тексту, должны указываться в этом операторе наряду с параметром directory.

Файл настройки для первичного мастер-сервера содержит по одной строке для каждого файла данных зоны, который следует учитывать. В BIND 4 такая строка состоит из трех полей - слова primary (начинающегося в первой позиции строки), доменного имени зоны и имени файла:

primary     myco.ru                  db.myco.ru

primary     100.168.192.in-addr.arpa db.192.168.100

primary     200.168.192.in-addr.arpa db.192.168.200

primary     0.0.127.in-addr.arpa   db.127.0.0

В BIND 8 и 9 эта строка начинается с ключевого слова zone, продолжается доменным именем и именем класса (in - класс Интернета). Тип master эквивалентен типу primary для BIND 4. Последнее поле содержит имя файла:

zone "myco.ru" in {

type master;
file "db.myco.ru";

};

Мы упоминали, что если не указывать класс данных в RR-записи, DNS-сервер определит класс, исходя из данных в файле настройки.

Указание in в операторе zone устанавливает класс данных Интернета. Для оператора zone в BIND 8 и 9 класс in является классом по умолчанию, так что его можно не указывать для зон класса Интернета. Поскольку в синтаксисе BIND 4 не предусмотрено указание класса зоны, по умолчанию также принимается значение in.

Вот строка файла настройки BIND 4, предписывающая чтение файла корневых указателей:

cache . db.cache

а вот эквивалентная строка для файла настройки BIND 8 или 91:

zone "." in {

type hint;
file "db.cache";

};

Как ранее уже говорилось, этот файл не содержит данные кэша, а только указатели (hints) корневых DNS-серверов.

По умолчанию BIND 4 читает файл настройки с именем /etc/named.boot, но этот параметр можно изменить с помощью ключа командной строки. BIND 8 и 9 ожидают найти файл настройки /etc/named.conf вместо /etc/named.boot. Файлы данных зоны в нашем примере расположены в каталоге /var/named. В каком именно каталоге они будут расположены в той или иной системе - особого значения не имеет. Следует избегать лишь помещения этого каталога в корневую файловую систему, если ощущается нехватка места в этой системе, а также следить за тем, чтобы файловая система, содержащая этот каталог, была смонтирована до запуска DNS-сервера. Вот полностью файл /etc/ named.boot для BIND 4:

; Файл настройки BIND directory /var/named

primary    myco.ru                  db.myco.ru

primary    100.168.192.in-addr.arpa db.192.168.100

primary    200.168.192.in-addr.arpa db.192.168.200

primary    0.0.127.in-addr.arpa   db.127.0.0

cache                               db. cache

А вот полный файл /etc/named.conf для BIND 8 и 9:

// Файл настройки BIND

options {

directory "/var/named"
// Дополнительные параметры

};

zone "myco.ru" in {

type master;
file "db.myco.ru";

};

zone "100.168.192.in-addr.arpa" in {

type master;
file "db.192.168.100";

};

zone "200.168.192.in-addr.arpa" in {

type master;
file "db.192.168.200";

};

zone "0.0.127.in-addr.arpa" in {

type master;
file "db.127.0.0";

};

zone "." in {

type hint;
file "db.cache";

};

Сокращения

Итак, мы создали все файлы, необходимые для работы первичного мастер-сервера DNS. Теперь взглянем еще раз на файлы данных зоны, некоторые углы мы не стали срезать, и сейчас самое время это сделать. Но, не зная, как выглядит полная форма записи, можно совершенно запутаться в краткой форме. Поскольку читатели уже знают, как выглядит полная форма файла настройки BIND, переходим к сокращениям.

Добавление доменных имен

Второе поле директивы primary (BIND 4) или оператора zone (BIND 8 и 9) определяет доменное имя. Это доменное имя является ключом к наиболее полезному типу сокращений. Оно является суффиксом по умолчанию (origin) для всей информации в файле данных зоны. Суффикс по умолчанию добавляется ко всем именам в файле данных зоны, которые не заканчиваются точкой, и поскольку каждый файл описывает отдельную зону, суффиксы по умолчанию в разных файлах различны.

Поскольку имя суффикса по умолчанию добавляется в конец остальных имен, для адреса fin.myco.ru в файле db.myco.ru можно указать вместо:

fin.myco.ru.  IN A 192.168.100.2

вот такую строку:

fin IN A  192.168.100.2

В файле db.192.168.100 полная запись выглядит так:

2.100.168.192.in-addr.агра.  IN PTR fin.myco.ru.

Поскольку 100.168.192.in-addr.агра является суффиксом по умолчанию, можно заменить ее на следующую:

2  IN PTR fin.myco.ru.

Если помните, мы предупреждали, что не следует забывать ставить точку в конце полных доменных имен. Предположим, вы забыли поставить последнюю точку. И запись:

fin.myco.ru       IN A        192.168.100.2

превратится в запись для fin.myco.ru.myco.ru, то есть мы получим совершенно нежелательный результат.

Запись через @

Если доменное имя совпадает с суффиксом по умолчанию, его можно указывать в виде «@». Чаще всего такая запись встречается в SOA-записях в файлах данных зоны. Выглядит это следующим образом:

@ IN SOA vova.myco.ru. fin.myco.ru. (
1     ; Порядковый номер
3h    ; Обновление через 3 часа
1h    ; Повторение попытки через 1 час
1w    ; Устаревание через 1 неделю
1h )  ; Отрицательное TTL в 1 час

Повтор последнего имени

Если имя RR-записи (начинающееся в первой позиции строки) состоит из пробелов или символа табуляции, то автоматически подставляется имя из предыдущей записи. Это можно использовать при необходимости создать несколько записей для одного имени. Приведем пример использования одного имени для создания двух записей:

lin  IN A   192.168.100.1

IN A   192.168.200.1

Во второй адресной записи неявно указывается имя lin. Этим сокращением можно пользоваться даже в случаях, когда RR-записи имеют разные типы.

Сокращенные файлы данных зоны

Теперь, когда мы ознакомились с сокращениями, повторим файлы данных для зоны, применив эти сокращения на деле.

Содержимое файла db.myco.ru:

$TTL 3h
;
; Суффикс по умолчанию, добавляемый ко всем именам,
; не заканчивающимся точкой: myco.ru
;
@ IN SOA vova.myco.ru. al.fin.myco.ru. (
1     ; Порядковый номер
Зh    ; Обновление через 3 часа
1h    ; Повторение попытки через 1 час
1w    ; Устаревание через 1 неделю
1h )  ; Отрицательное TTL в 1 час
;
; Серверы имен (неявно указано имя '@')
;
IN NS vova.myco.ru.
IN NS lin.myco.ru.
;
; Адреса для канонических имен
;
localhost IN A 127.0.0.1
fin IN A 192.168.100.2
vova IN A 192.168.100.3
al IN A 192.168.100.4
misery IN A 192.168.200.2
shining IN A 192.168.200.3
carrie IN A 192.168.200.4
lin IN A 192.168.100.1
IN A 192.168.200.1

; Псевдонимы

bigt IN CNAME vova
dh IN CNAME al
wh IN CNAME lin

; Специальные имена интерфейсов

wh100 IN A 192.168.100.1
wh200 IN A 192.168.200.1

А вот содержимое файла db. 192.168.100:

$TTL 3h

; Суффикс по умолчанию, добавляемый ко всем именам,
; не заканчивающимся точкой: 100.168.192.in-addr.arpa

@ IN SOA vova.myco.ru. fin.myco.ru. (
1     ; Порядковый номер
Зh    ; Обновление через 3 часа
1h    ; Повторение попытки чере 1 час
1w    ; Устаревание через 1 неделю
1h )  ; Отрицательное TTL в 1 час

; Серверы имен (неявно указано имя '@')

IN NS vova.myco.ru.
IN NS lin.myco.ru.

; Адреса, указывающие на канонические имена

1  IN   PTR  lin.myco.ru.

2  IN   PTR   fin.myco.ru.

3  IN   PTR   vova.myco.ru.

4  IN   PTR   al.myco.ru.

И содержимое файла db.192.168.200:

$TTL 3h

; Суффикс по умолчанию, добавляемый ко всем именам,
; не заканчивающимся точкой: 200.168.192.in-addr.arpa

@ IN SOA vova.myco.ru. fin.myco.ru. (
1     ; Порядковый номер
Зh    ; Обновление через 3 часа
1h    ; Повторение попытки чере 1 час
1w    ; Устаревание через 1 неделю
1h )  ; Отрицательное TTL в 1 час

; Серверы имен (неявно указано имя '@')

IN NS vova.myco.ru.
IN NS lin.myco.ru.

; Адреса, указывающие на канонические имена

1  IN   PTR  lin.myco.ru.

2  IN   PTR   misery.myco.ru.

3  IN   PTR   shining.myco.ru.

4  IN   PTR   carrie.myco.ru.

Содержимое файла db. 127.0.0:

$TTL 3h

@ IN SOA vova.myco.ru. al.fin.myco.ru. (

1    ;    Порядковый номер

3h   ;    Обновление через 3 часа

1h   ;    Повторение попытки через 1 час

1w   ;    Устаревание через 1 неделю

1h ) ;   Отрицательное TTL в 1 час

IN NS vova.myco.ru.
IN NS lin.myco.ru.

1 IN PTR localhost.

Читатели могли заметить, что в новой версии файла db.myco.ru можно было бы удалить myco.ru из имен узлов в записях SOA и NS следующим образом:

@ IN SOA vova al.fin (

1     ; Порядковый номер

3h    ; Обновление через 3 часа

1п    ; Повторение попытки через 1 час

1w    ; Устаревание через 1 неделю

1h )  ; Отрицательное TTL в 1 час

IN NS vova
IN NS lin

Но так нельзя делать в прочих файлах данных зоны, поскольку они имеют отличные суффиксы по умолчанию. В файле db.myco.ru мы оставили полные доменные имена, чтобы записи SOA и NS были абсолютно одинаковыми во всех файлах данных зоны

Запуск первичного мастер-сервера DNS

Итак, создав файлы данных для зоны, мы готовы к запуску пары DNS-серверов. Речь идет об основном контрольном сервере имен и вторичном сервере имен. Однако прежде чем запускать DNS-сервер, следует убедиться, что запущен демон syslog. Если DNS-сервер при чтении файла настройки или зональных данных находит ошибку, информация об этой ошибке заносится в log-файл с помощью демона syslog. Если ошибка критическая, DNS-сервер прекращает работу.

Запуск DNS-сервера

Мы предполагаем, что к данному моменту на машине уже установлен DNS-сервер BIND и программа nslookup. Сверьтесь с руководством по named в поисках каталога, который содержит исполняемый файл сервера, и убедитесь, что этот исполняемый файл присутствует в системе. В системах BSD DNS-сервер начинал свое существование в каталоге /etc, но вполне мог переместиться в /usr/sbin. Также named можно поискать в /usr/etc/in.named и /usr/sbin/in.named. Последующие описания подразумевают, что файл расположен в каталоге /usr/sbin.

Чтобы запустить сервер, следует получить полномочия суперпользователя (root). Сервер имен принимает запросы через привилегированный порт, а для этого требуются права пользователя root. На первый раз запустите DNS-сервер из командной строки, чтобы убедиться в его корректной работе.

Следующая команда запускает DNS-сервер. Мы выполнили ее на узле lin.myco.ru:

# /usr/sbin/named

Такая команда подразумевает, что файлом настройки является /etc/ named.boot (BIND 4) или /etc/named.conf (BIND 8 или 9). Файл настройки может находиться в другом месте, но в этом случае следует указать DNS-серверу - где именно, используя ключ -с:

# /usr/sbin/named -с conf-file

Ошибки в log-файле syslog

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

% gгер daemon /etc/syslog.conf

*.err;kern.debug;daemon,auth.notice /var/adm/messages

На этом узле syslog-сообщения от DNS-сервера заносятся в log-файл, хранимый в файле /var/adm/messages, и при этом syslog пропускает только сообщения, которые имеют приоритет LOG_NOTICE или более высокий. Некоторые полезные сообщения имеют приоритет LOGINFO - и вы можете захотеть их прочитать.

При запуске DNS-сервера в log-файл заносится стартовое сообщение:

% дгер named /var/adm/messages

Jan 10 20:48:32 vova named[3221]: starting.

Стартовое сообщение не является сообщением об ошибке, но за ним могут следовать другие сообщения, обладающие этим свойством. (Если сервер сообщает restarted (перезапуск) вместо starting, это тоже вполне нормально. Это сообщение изменилось в BIND версии 4.9.3.)

НОВОСТИ: Выпуск GNU APL 1.8 Sun, 23 Jun 2019 20:29:05 +0300

После более двух лет разработки проект GNU представил выпуск GNU APL 1.8, интерпретатора для одного из старейших языков программирования - APL, полностью удовлетворяющего требованиям стандарта ISO 13751 ("Programming Language APL, Extended"). Язык APL отличается оптимизацией для работы с массивами произвольной вложенности и поддержкой комплексных чисел, что делает его востребованным для научных расчётов и обработки данных. В начале 1970-х годов идея APL-машины дала толчок к созданию первого в мире персонального компьютера IBM 5100. APL также пользовался большой популярностью на советских ЭВМ начала 80-х годов. Из современных систем, основанных на идеях APL, можно отметить вычислительные среды Mathematica и MATLAB.

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome