Dns сервер linux или

Установка и настройка DNS-сервера BIND в Linux

BIND – наиболее распространенное open-source приложение, в котором реализованы протоколы DNS, предоставляющие возможность преобразования доменных имен в IP-адреса и наоборот.

Данная статья представляет собой руководство по быстрой настройке DNS-сервера в Linux при помощи BIND. Мы не будем подробно разбирать, что такое система DNS и как она работает, а сосредоточимся на примере настройки своей зоны и файла конфигурации для домена/узла с поддержкой сервисов www и электронной почты.

В нашем примере мы будем использовать следующие параметры:
IP-адрес, на котором будет установлен сервер имен: 172.31.0.122
имя домена/узла: itproffi.ru
авторитативные сервера имен для зоны itproffi.ru: ns1.itproffi.ru (172.31.1.10) и ns2. itproffi.ru (172.31.1.11)
службы www и электронной почты для itproffi.ru будут использовать адрес 172.31.1.10

Установка сервера bind

Установка bind очень проста – нужно воспользоваться менеджером пакетов. В Debian и Ubuntu выполните следующую команду:

В CentOS или Fedora:

Пакет dnsutils необязателен для запуска сервера bind, но для тестирования конфигурации мы будем пользоваться командой dig из этого пакета.

Создание файла зоны DNS

Дальнейшие примеры будут для Ubuntu/Debian, но также подходят и для Centos/RedHat, только директория с настройками зон в CentOS будет находиться в /etc/named/ , а основной файл конфигурации /etc/named.conf . Для начала нам потребуется создать новый файл зоны для домена itproffi.ru. Перейдите в директорию /etc/bind/ . создайте в ней поддиректорию zones/master/ и перейдите в нее, выполнив следующую последовательность команд:

Директория /etc/bind/zones/master будет содержать файл зоны для домена itproffi.ru. При желании можно использовать другую директорию. Файл зоны db.itproffi.ru будет содержать запись DNS, которая поможет серверу имен установить соответствие полного доменного имени IP-адресу. Создайте этот файл со следующим содержимым:

Рассмотрим ключевые строки этого файла:

• Запись SOA: авторитативный сервер имен для itproffi.ru – это ns1.itproffi.ru, адрес ответственного за зону DNS администратора – admin@itproffi.ru
• Записи NS: два сервера имен для зоны itproffi.ru – ns[1,2].itproffi.ru
• Запись MX: почтовый сервер для itproffi.ru. Число 10 означает уровень приоритета
• Записи A: A означает «адрес» (address). Другими словами, ns1 в зоне itproffi.ru будет иметь адрес 172.31.1.10
• Запись CNAME (Canonical Name – каноническое имя): привязывает одно доменное имя к другому (каноническому), например, устанавливает соответствие mail.itproffi.ru и itproffi.ru.

Настройка обратной зоны

На данном этапе DNS-сервер bind может выдать IP-адрес, связанный с узлом itproffi.ru. Теперь нам нужно научить наш сервер имен обратному процессу, то есть устанавливать соответствие имени IP-адресу. Для этого создадим еще один файл db.172.31.1 со следующим содержимым:

Запись PTR: DNS-запись, используемая для определения соответствия IP-адреса имени узла.

Настройка файла конфигурации bind

На данный момент у нас должно быть два файла:

Теперь требуется вставить имена обоих файлов зоны в файл конфигурации bind /etc/bind/named.conf.local . Для этого добавьте в файл следующие строки:

Последний момент перед проверкой конфигурации – внести в файл named.conf.options IP-адрес стабильного DNS-сервера. Он будет использоваться, если локальный DNS-сервер не будет знать ответ на запрос разрешения имени. Часто этот адрес предоставляется интернет-провайдером, но если вы поклонник Google, можно указать адрес 8.8.8.8 или 8.8.4.4.

Замените следующий блок текста в файле named.conf.options:

на блок текста с адресом стабильного DNS-сервера

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

А лучше, для безопасности вместо any пропишите ваши сети с которых разрешено подключение

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

Проверка файлов зоны и конфигурации

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

Для проверки файлов конфигурации выполните следующую команду:

С этой командой работает простое правило: отсутствие результата – это хороший результат. Если команда ничего не возвращает, значит ошибок в ваших файлах конфигурации не обнаружено.

Для проверки файлов зоны DNS можно воспользоваться командой named-checkzone:

Проверка обратной зоны

Запуск и перезапуск сервера bind

Теперь мы можем запускать сервер bind:

Если сервер уже был запущен, его можно перезапустить командой restart:

Для того что бы перечитать конфигурацию не перезапуская сервер, используйте команду

Тестирование сервера bind

Для тестирования новой конфигурации сервера имен bind нам пригодится команда dig из пакета dnsutils. Эту команду можно запустить на любом компьютере с сетевым доступом к вашему DNS-серверу, но лучше всего начать тестирование с локального узла. В рассматриваемом нами примере IP-адрес сервера имен 172.31.0.122. Сначала проверим прямое разрешение имени (получение IP-адреса по доменному имени):

dig @172.31.0.122 www.itproffi.ru

Теперь проверим обратную зону:

dig @172.31.0.122 -x 172.31.1.10

Если вы получили аналогичные результаты, то зона DNS настроена правильно. Вместо команды dig для тестирования можно также использовать команду nslookup.

nslookup 172.31.1.10 172.31.0.122

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

Источник

Серверы Linux. Часть III. Сервер DNS

Глава 4. Вводная информация о серверах DNS

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

Каждый раз при посещении веб-сайта, отправке сообщения электронной почты, входе в домен Active Directory, игре в Minecraft, переписке в сетевом чате или использовании технологии VoIP осуществляется отправка одного (или множества) запросов серверу DNS .

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

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

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

В данном разделе даются пояснения относительно принципа работы серверов DNS , а также процесса настройки сервера bind9 при работе с дистрибутивом Linux .

4.1. О протоколе DNS

4.1.1. Преобразование доменного имени в IP-адрес

Система доменных имен ( Domain Name System или DNS ) является сетевой службой, работающей со стеком протоколов TCP/IP и позволяющей клиентам преобразовывать доменные имена в IP-адреса. На самом деле с помощью аббревиатуры DNS обозначается инфраструктура гораздо большего масштаба, но на данный момент благоразумнее рассмотреть упрощенный вариант.

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

При работе со сниффером Wireshark вы можете использовать фильтр dns для перехвата соответствующего трафика.

4.1.2. История создания протокола DNS

В семидесятые годы к сети Интернет было подключено всего несколько сотен компьютеров. Для разрешения доменных имен на каждом из этих компьютеров использовался текстовый файл, содержащий таблицу из доменных имен и соответствующих им IP-адресов. Этот локальный файл являлся копией файла hosts.txt , расположенного на FTP-сервере Университета Стэнфорда.

В 1984 году Paul Mockapetris создал систему DNS , являющуюся распределенной древовидной иерархической базой данных, которая будет подробно описываться в нескольких главах данной книги.

На сегодняшний день система доменных имен ( Domain Name System или DNS ) является общемировой распределенной иерархической базой данных, находящейся под контролем организации ICANN . Ее главная функция заключается в преобразовании доменных имен в IP-адреса и указании на серверы в сети Интернет, предоставляющие сервисы SMTP и LDAP .

Старый файл hosts.txt по прежнему активно используется в большинстве операционных систем под именем /etc/hosts (или C:/Windows/System32/Drivers/etc/hosts). Далее мы вернемся к рассмотрению этого файла, а также его влияния на процесс разрешения доменных имен.

4.1.3. Прямой и обратный запросы

Вопрос, задаваемый клиентом серверу DNS, называется запросом (DNS query). В ситуации, когда клиент запрашивает IP-адрес узла говорят о прямом запросе DNS (forward lookup query, как было показано на предыдущей иллюстрации).

Противоположный по смыслу запрос доменного имени узла называется обратным запросом DNS (reverse lookup query).

Ниже приведена иллюстрация обратного запроса DNS .

А это пример осуществления обратного запроса DNS с помощью утилиты nslookup .

В случае использования сниффера tcpdump обратный запрос DNS будет выглядеть аналогичным образом.

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

4.1.4. Файл /etc/resolv.conf

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

Клиентские системы Linux хранят упомянутую информацию в файле /etc/resolv.conf .

Вы можете вручную осуществить модификацию IP-адреса с пометкой nameserver для использования другого сервера DNS . Например, компания Google предоставляет доступ к публичному серверу DNS с IP-адресами 8.8.8.8 и 8.8.4.4.

Обратите внимание на то, что при использовании клиента DHCP данные IP-адреса могут быть перезаписаны в процессе обновления базы данных адресов DHCP ( DHCP lease ).

4.2. Пространство имен DNS

Пространство имен DNS является иерархической древовидной структурой с корневыми серверами ( root-servers или dot-servers ) на вершине. Корневые серверы обычно обозначаются с помощью точки.

Далее мы будем говорить не о корневых серверах , а о доменах верхнего уровня ( Top Level Domains или TLDs ).

Существует гораздо большее количество доменов верхнего уровня , нежели показано на иллюстрации. На данный момент около 200 стран имеют домены верхнего уровня . Кроме того, существует множество доменов верхнего уровня общего назначения, таких, как .com, .edu, .org, .gov, .net, .mil, .int, а также сравнительно недавно введенных в строй .aero, .info, .museum,

4.2.2. Корневые серверы

В рамках сети Интернет существует тринадцать корневых серверов DNS , которые носят имена от A до M . Журналисты обычно называют эти серверы основными серверами сети Интернет , так как в том случае, если они выйдут из строя, никто не сможет использовать доменные имена для соединения с серверами, на которых расположены веб-сайты.

Корневые серверы не расположены на тринадцати физических машинах, они распределены по гораздо большему количеству машин. К примеру, корневой сервер с именем F распределен по 46 физическим машинам, которые функционируют как одна машина благодаря осуществлению произвольной передачи данных (anycast).

4.2.3. Данные для поиска корневых серверов

В комплект поставки каждого сервера DNS включается файл с данными для поиска корневых серверов ( root hints ), который предназначен для поиска корневых серверов DNS .

В данном примере показан небольшой фрагмент файла с данными поиска корневых серверов из комплекта поставки сервера DNS bind 9.8.4 .

На следующем уровне древовидной структуры после доменов верхнего уровня располагаются обычные домены . Домены могут иметь субдомены (также называемые дочерними доменами).

На иллюстрации показаны такие домены системы доменных имен DNS , как google.com, chess.com, linux-training,be (при этом не стоит забывать о существовании миллионов других доменов).

Домены системы доменных имен DNS регистрируются на серверах, обслуживающих домены верхнего уровня , а домены верхнего уровня — на корневых серверах .

4.2.5. Домены верхнего уровня

На уровне древовидной структуры ниже корневых доменов расположены домены верхнего уровня ( Top Level Domains или TLDs ). Изначально было зарегистрировано лишь семь таких доменов:

Таблица 4.1. Первые домены верхнего уровня

Год регистрации	Домен верхнего уровня	Назначение
1985	.arpa	Домен для обработки обратных запросов DNS с использованием специального домена in-addr.arpa
1985	.com	Домен для коммерческих организаций
1985	.edu	Домен для образовательных учреждений США
1985	.gov	Домен для правительственных учреждений США
1985	.mil	Домен министерства обороны США
1985	.net	Домен для интернет-провайдеров и организаций, обслуживающих инфраструктуру сети Интернет
1985	.org	Домен для некоммерческих организаций
1985	.int	Домен для международных организаций, таких, как NATO (nato.int)

Домены верхнего уровня отдельных стран регистрировались в разное время, например, домен .uk для Великобритании был зарегистрирован в 1985 году (да, это было именно так), домен .be для Бельгии — 1988 году, а домен . fr для Франции — в 1986 году. Обратитесь к стандарту RFC 1591 для получения дополнительной информации.

В 1998 году было выбрано семь новых доменов верхнего уровня , которые стали активны лишь в 21 веке.

Таблица 4.2. Новые домены верхнего уровня общего назначения

Год регистрации	Домен верхнего уровня	Назначение
2002	.aero	Домен для ресурсов, связанных с авиацией
2001	.biz	Домен для ресурсов, связанных с бизнесом
2001	.coop	Домен для ресурсов, связанных с кооперацией
2001	.info	Домен для информационных ресурсов
2001	.museum	Домен для ресурсов музеев
2001	.name	Домен для ресурсов, связанных с любыми видами имен, псевдонимов и названий.
2004	.pro	Домен для ресурсов квалифицированных специалистов

Многие администраторы ресурсов были удивлены выбором доменов верхнего уровня и заявили о том, что этим доменам достаточно сложно найти применение и они хотели бы использовать отдельный домен .xxx для размещения ресурсов для взрослых (был представлен в 2011 году), а также домен .kidz для ресурсов с информацией о детях, от которых отказались родители. В то же время были зарегистрированы еще более бесполезные домены верхнего уровня , такие, как .travel (для ресурсов агентств путешествий), .tel (для ресурсов, связанных с интернет-коммуникациями) и .jobs (для ресурсов по поиску работы).

В 2012 году организация ICANN опубликовала список из 2000 новых доменов верхнего уровня , которые будут постепенно регистрироваться.

4.2.6. Полностью определенное доменное имя

Полностью определенное доменное имя ( Fully Qualified Domain Name или FQDN ) является комбинацией из имени узла машины и соответствующего доменного имени .

Например, в том случае, если система носит имя gwen и использует домен linux-training.be , полностью определенным доменным именем системы будет gwen.linux-training.be .

В системах Linux вы можете использовать утилиты hostname и dnsdomainname для проверки данной информации.

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

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

Зона DNS состоит из записей , которые также называют ресурсными записями . В следующем разделе мы рассмотрим некоторые из упомянутых ресурсных записей .

4.2.7. Ресурсные записи DNS

Запись A , которая также называется записью узла ( host record ) содержит IP-адрес компьютера в формате IPv4. В момент, когда клиент DNS отправляет серверу DNS запрос данных записи A, сервер DNS осуществляет преобразование переданного с запросом доменного имени в IP-адрес. Запись AAAA аналогична рассматриваемой записи, но содержит IP-адрес формата IPv6, а не IPv4.

Запись PTR является полной противоположностью записи A. Она содержит имя компьютера и может использоваться для преобразования IP-адреса в имя узла.

Запись NS или запись сервера имен ( nameserver record ) является записью, которая указывает на сервер имен DNS (обслуживающий данную зону DNS). Вы можете получить список всех серверов имен для вашей зоны DNS, получив данные отдельных записей NS.

Связующая запись A

Запись A, которая устанавливает соответствие между именем записи NS и IP-адресом называется связующей записью .

Запись SOA зоны DNS содержит метаданные, относящиеся к самой зоне DNS. Записи SOA подробно описаны в разделе, посвященном передачам данных зон DNS. В каждой из зон DNS существует ровно по одной записи SOA.

Запись CNAME устанавливает соответствие между двумя именами узлов, позволяя создать новый псевдоним для существующего имени узла. В качестве имени почтового сервера обычно используются имена mail и smtp , а в качестве имени веб-сервера — www .

Запись MX указывает на сервер SMTP . При отправке сообщения электронной почты по адресу в другом домене, вашему почтовому серверу потребуется запись MX почтового сервера из целевого домена.

Источник