» » Конфигурирование dns сервера

16-07-2017, 18:07

Конфигурирование dns сервера

Конфигурирование файлов DNS

Mon, 16 Feb Конфигурирование DNS-сервера BIND Оригинал: Рассматриваются не только вопросы настройки сервера, доменных зон, но и ряд функциональных возможностей, повышающих безопасность работы данного сервиса.

Особенности реализации службы dns в Windows 2000

Введение DNS-сервис является одним из важных сервисов для нормального функционирования Internet сети. Его основная задача состоит в определении соответствия между сетевыми адресами узлов сети и их удобочитабельными названиями.

Существует два варианта определения этого соответствия - прямое и реверсивное определение. При прямом разрешении DNS-сервер по имени определяет и выдает сетевой адрес, а при реверсивном - по адресу ищет соответствующее имя.

Это необходимо учитывать при настройке DNS-сервиса, поскольку для осуществления данных механизмов используются разные таблицы. В операционной системе Sun Solaris, как, в прочем, и в других UNIX-системах, в качестве DNS-сервера используется BIND-сервер версии 8. Хотя, нужно заметить, в Solaris-е есть возможность использования и сервера версии 4. Если используется файл - named. Лучше естественно использовать BIND 8. Если у вас остались конфигурационные файлы named.

Строгое имя сборки вычисляет кэш или контрольную сумму подписываемой сборки и тем самым гарантирует ее подлинность для клиентского приложения или почти гарантирует. Технология использования "strong name" определяется правилами использования криптографических ключей в конкретной организации. Рассмотрим алгоритм формирования строгих имен сборок в наиболее общем виде. Данный DNS-сервер является головным для данного домена.

Такие DNS-серверы хранят копии доменных зон, которые скачивают и периодически обновляют с master-сервера.

Не хранит никаких таблиц зон, а просто собирает с объявленных root-серверов кэш резолвенных адресов. Используется для повышения эффективности работы DNS-сервера. Очевидно, что вы можете настроить так ваш BIND-сервер, что он одновременно может обслуживать несколько разных доменных зон и для одних он может быть master-ом, для других - slave и тд. В любом случае, какие-бы типы зон вы не настраивали, две зоны будут присутствовать у вас почти всегда - это зона hint и localhost прямая и реверсивная.

Итак, начнем с просто кэширующего DNS-сервера. Структура options - описывает глобальные параметры для сервера, а структуры zone - описывают, соответственно, доменные зоны. Тут прописываем адрес локального интерфейса, у меня это В нашем случае трансфер запрещен. Мы прописали нашу локальную сетку Я указал first - это означает что сервер сначала перенаправит запрос выше и если не получит положительного результата, то посмотрит в своем кэше.

Если указать only - то у себя смотреть не будет -forwarders - а тут вы и указываете куда перенаправлять запросы клиентов. Я указал, для примера, свой вышестоящий DNS-сервер Удалил опции определяющие форвард запросов и пока не разрешаю трансфер своих таблиц. Таким образом у меня получился мастер DNS-сервер для моего домена sun. Теперь настроим наш BIND в случае когда у нас существуют и slave-серверы.

Сначала необходимо подправить на мастер-сервере возможность передачи таблиц зон. Для этого нужно только разрешить трансфер зон: А теперь на slave-сервере делаем конфигурационный файл: Несколько слов о том, как запускать и останавливать bind-демон и где читать логи: Таблицы зон Теперь приступаем к созданию таблиц зон. Понятно, что для slave-сервера большинство таблиц будут скачены с master-сервера.

Первым делом пропишим таблицы для localhost и зоны hint.

конфигурирование dns сервера

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

Настройка DNS-сервера для использования серверов пересылки

Дело в том, что ваш сервер при каждом запуске и по истечении параметра TTL time-to-live будет обращаться ко всем серверам из этого файла и, таким образом, создаст вам огромный трафик, хотя накопленной информации, хранящейся на сервере вашего провайдера, вполне для вас будет достаточно.

В качестве примера я написал только один адрес А-root сервера, если вы хотите добавить еще сервера, то создайте B,C,D Расшифровка полей файлов зон: Самый лучший формат - ГГГГММДДNN, где NN - номер изменения таблицы за текущий день ;refresh - время в секундах, указывающее как часто необходимо проверять таблицу мастер-сервера на необходимость update-а ;retry - время в секундах, которое сервер ожидает при ошибочном сеансе refresh-а чтобы начать его заново ;expiry - максимальный предел в секундах времени хранения таблицы, по его истечении таблица считается устаревшей и скачивается заново.

Конфигурирование DNS-сервера BIND (dns bind domain)

Время в секундах, которое указывает серверу сколько хранить в кэше данные таблицы. По его истечении срвер перечитывает таблицу заново. IN MX 10 solaris.

конфигурирование dns сервера

Если ее не ставить, то сервер автоматически допишет название домена для которого данная таблица и составляется. Не забывайте про это. Вот и все, если таблицы готовы, то теперь можно и запускать ваш сервер. Как это делать мы уже рассмотрели выше. Передача зон по защищенному ключу Если перед вами стоит задача повысить уровень безопасности при трансфере таблиц между master и slave серверами, то необходимо наложить дополнительную аутентификацию на этот механзм. Вообще, механизм аутентификации по ключу, который мы сейчас настроим, может применяться не только при передаче зон, но и даже при обработке запросов клиент-сервер.

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

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

конфигурирование dns сервера

На slave-серверах необходимо, так же, прописать аналогичные структуры. Причем структура key - "один в один" - иначе не пройдет аутентификация, а вот структура server должна быть одна с адресом вашего master-сервера.

Конфигурирование DNS-сервера BIND (Master & Slave)

Вот и все, запускаете службу и если не ошиблись при наборе ключа серверы начнут трансфер зон. Единственно на что еще хочется обратить внимание - это на синхронизацию времени между master и slave серверами. Если трансфер зон не прошел, то читайте лог - там причина будет описана. Если ошиблись в ключе - проверяйте его идентичность, если не совпадает время - синхронизируйте его команды date, rdate либо запустите ntp механизм и все будет - ОК!

Найдите там следующую строчку и допишите как это показано у меня: Причем опрос идет в порядке сверху-вниз и максимальное количество объявленных северов - три. Вот и все что нужно сделать, все значения система подхватывает "на лету".

установка bind linux, настройка DNS server, master & slave servers

Не хочется утомлять Вас банальностями, объясняющими влияние полнолуния на безопасность информационных систем

Рекомендуем посмотреть:
Комментарии (0)