Dns linux обратная зона dns

Установка и настройка 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.

Источник

4.3 Обратная (reverse) зона

Теперь программы могут преобразовывать имена машин в домене linux.bogus в адреса, по которым они могут связаться с этими машинами. Но также, кроме этого, требуется обратная зона, которая дает возможность DNS преобразовывать адреса в имена машин. Эти имена используются достаточным количеством серверов различного рода (FTP, IRC, WWW и другими) для того, чтобы решить, хотят ли они с вами общаться или нет, и даже иногда имя машины используется для того, чтобы решить какой приоритет вам дать. Обратная зона требуется для полного доступа к различным сервисам в Internet.

Поместите следующие строки в файл named.conf :

zone «196.168.192.in-addr.arpa» <
notify no;
type master;
file «pz/192.168.196»;
>;

Эти строки похожи на описание зоны 0.0.127.in-addr.arpa , а файл зоны также имеет сходное содержание:

@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Serial, todays date + todays serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.

1 PTR gw.linux.bogus.
2 PTR ns.linux.bogus.
3 PTR donald.linux.bogus.
4 PTR mail.linux.bogus.
5 PTR ftp.linux.bogus.

Теперь перезапустите ваш named ( ndc restart ) и снова проверьте его работу с помощью программы nslookup :

> 192.168.196.4
Server: localhost
Address: 127.0.0.1

Name: mail.linux.bogus
Address: 192.168.196.4

так, это выглядит нормально, теперь выдайте полный список машин в домене, для того чтобы проверить правильность информации:

> ls -d 196.168.192.in-addr.arpa
[localhost]
$ORIGIN 196.168.192.in-addr.arpa.
@ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum

1D IN NS ns.linux.bogus.
1 1D IN PTR gw.linux.bogus.
2 1D IN PTR ns.linux.bogus.
3 1D IN PTR donald.linux.bogus.
4 1D IN PTR mail.linux.bogus.
5 1D IN PTR ftp.linux.bogus.
@ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum

Выглядит хорошо! Если вывод вашей команды выглядит не так, то посмотрите сообщения об ошибках в вашем syslog , я объяснял как это сделать в самом начале главы.

Источник

Dns linux обратная зона dns

Как установить свой собственный домен

До того как мы в действительности начнем этот раздел, я хочу дать вам некоторые теоретические сведения о том как работает DNS и пример ее работы. И вы должны читать дальше, потому что это полезно для вас. Если вы не `хотите’ делать это, то вы по крайней мере должны быстро просмотреть его. Остановитесь, когда вы увидите указания о том, что вы должны делать с вашим файлом named.conf .

DNS — это иерархическая, организованная в виде дерева система. Вершина записывается как ` . ‘ и произносится как `root (корень)’. В . существует некоторое количество Доменов верхнего уровня (Top Level Domains, TLDs), наиболее известными из которых являются ORG, COM, EDU и NET, но на самом деле их намного больше. ТОчно также как и дерево, они имеют корни и ветви. Если у вас есть некоторое образование в области компьютерных наук, то вы сможете думать о DNS как о дереве поиска, и вы сможете находить узлы, листья и связи между вершинами этого дерева.

При поиске машины, запрос обрабатывается рекурсивно, начиная с корня. Если вы хотите найти адрес машины prep.ai.mit.edu , то ваш сервер имен должен найти сервер имен, который обслуживает edu . Он запрашивает корневой сервер ( . ) (он уже знает корневые . сервера — они перечислены в файле root.hints ), корневой сервер . дает список серверов edu :

Это дает нам информацию о том, что все ROOT-SERVERS.NET обслуживают edu. , так что мы можем продолжать опрашивать сервер C . Теперь мы хотим знать кто обслуживает следующий уровень имени домена: mit.edu. :

Так что museli.ai.mit.edu является сервером имен для ai.mit.edu :

Теперь я изменил тип запроса, поскольку мы нашли сервер имен и можем опрашивать его том, что мы хотим знать о prep.ai.mit.edu .

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

В аналогии с деревом каждый знак « . » в имени является точкой ответвления дерева. И каждая часть между знаками « . » является именем индивидуальной ветви в дереве.

Мы поднимаемся по дереву взяв нужное имя ( prep.ai.mit.edu ), потом находим корень дерева ( . ) и затем ищем следующую ветвь по которой будем подниматься, в нашем случае это edu . Однажды найдя эту ветвь, мы будем подниматься по ней, переключившись на сервер, который знает об этой части имени. Затем мы ищем ветвь mit в ветви edu (объединеное имя становится равным mit.edu ) и поднимаемся по ней, переключившись на сервер, который знает о mit.edu . Далее мы ищем слудующую ветвь— ai.mit.edu и переключаемся на сервер, который знает об этом домене. Теперь мы достигли нужного сервера в нужной точке ветвления. Последней задачей будет нахождение prep.ai.mit.edu , что является простой задачей. В научной литературе мы обычно называем машину prep листом дерева.

Менее обсуждаемым, но все равно важным является домен in-addr.arpa . Он также имеет иерархическую структуру, подобно `обычным’ доменам. in-addr.arpa позволяет нам получить имя машины, по ее адресу. Необходимо заметить, то что ip-адреса в домене in-addr.arpa записаны в обратном порядке. Например, Если у вас есть машина с адресом: 192.128.52.43, то named обрабатывает ее точно также как в примере для prep.ai.mit.edu : находит сервера arpa. . Находит сервера для домена in-addr.arpa. , находит сервера 192.in-addr.arpa. , находит сервера для 128.192.in-addr.arpa. , сервера для 52.128.192.in-addr.arpa. . А потом уже находит необходимые записи о 43.52.128.192.in-addr.arpa. Ловко? (скажите ‘да’). Хотя обратный порядок может смущать, но это только первые два года.

Я вам солгал. DNS не работает точно так, как я это описал. Но достаточно близко к описанному процессу.

Теперь определим наш собственный домен. Мы будем делать домен linux.bogus и определим машины в нем. Я использую полностью поддельное имя домена, для того чтобы быть уверенным, что мы не побеспокоим никого во внешнем мире.

Одно важное замечание до того как мы начнем: Не все символы разрешено использовать в именах машин. Мы ограничимся символами английского алфавита: a-z, цифрами: 0-9 и символом ‘-‘ (тире). Придерживайтесь использования этих символов. Прописные и строчные символы не различаются DNS, так что pat.uio.no является равным Pat.UiO.No .

Мы уже начали эту часть строкой в named.conf :

Заметьте отсутствие ` . ‘ в конце имен доменов в этом файле. Это указывает, что мы сейчас будем определять зону 0.0.127.in-addr.arpa , и что мы будем основным сервером для нее, а также то, что она хранится в файле, названном pz/127.0.0 . Мы уже сделали этот файл, в нем записано:

Заметьте наличие символа ` . ‘ в конце полных имен доменов в этом файле, в противоположность вышеприведенному файлу named.conf . Некоторые люди любят начинать каждый файл зон с директивы $ORIGIN , но это является излишним. Расположение (origin) (место зоны в иерархии DNS) файла зоны указывается в разделе зон в файле named.conf , в данном случае это 0.0.127.in-addr.arpa .

Этот `файл зоны’ содержит 3 `записи ресурсов (resource records)’ ( RR s): A SOA RR , A NS RR и PTR RR . SOA это сокращение для Начала Полномочий (Start Of Authority). Символ `@’ это специальный символ обозначающий расположение, и поскольку в колонке `домен (domain)’ для этого файла записано 0.0.127.in-addr.arpa , то первая строка на самом деле значит

NS это RR для сервера имен (Name Server). В начале строки символ ‘@’ не указывается, это подразумевается, поскольку предыдущая строка начиналась с символа ‘@’. Это сэкономит нам несколько нажатий на клавиши. Так что строка NS в действительности читается как

Эта строка сообщает DNS, что машина является сервером имен домена 0.0.127.in-addr.arpa , это ns.linux.bogus . ‘ns’ традиционное имя для серверов имен, но как и для web-серверов, чьим традиционным именем является www. что-нибудь , данное имя может быть любым.

И в в окончание — запись PTR гласит, что машина с адресом 1 в подсети 0.0.127.in-addr.arpa , например, 127.0.0.1 называется localhost .

Запись SOA находится в преамбуле каждого из файлов зон. Она описывает зону — откуда она появляется (машина, названная ns.linux.bogus ), кто отвечает за содержимое зоны ( hostmaster@linux.bogus , вы должны вставить здесь свой адрес электронной почты), какая версия файла зоны текущая (serial: 1), и другие вещи, которые надо сделать для кеширующих и вторичных серверов DNS. Для полей refresh, retry, expire и minimum используйте числа приведенные в этом документе и вы должны быть в безопасности, используя их.

Затем перезапустите ваш named (команда ndc restart ) и используйте программу nslookup для проверки того, что сделано:

Заметим, что мы продолжаем опускать завершающий символ ` . ‘ в имени домена в файле named.conf .

В файле зоны linux.bogus мы поместим некоторые поддельные данные:

Необходимо упомянуть две вещи о записи SOA. ns.linux.bogus должен быть настоящей машиной с записью A. Не разрешается указывать машину с записью CNAME в записи SOA. Это имя не обязательно должно быть `ns’, оно может быть любым правильным именем машины. Далее, hostmaster.linux.bogus должен читаться как hostmaster@linux.bogus, это должен быть почтовый псевдоним или почтовый ящик для человека сопровождающего DNS и читающего почту достаточно часто. Любая почта, относительно домена будет посылаться на адрес указаный здесь. Имя не обязательно должно быт `hostmaster’, это может быть любой правильный адрес электронной почты, но адрес с именем `hostmaster’ как ожидается будет работать.

В этом файле приведен еще один новый тип записи о ресурсах (RR) — MX, или запись ресурса Почтовый Сервер (Mail eXchanger). Она сообщает почтовой системе куда посылать почту адресованную someone@linux.bogus , а именно серверам mail.linux.bogus или mail.friend.bogus . Число перед каждым именем машины — это приоритет записи MX RR. Запись ресурса с наименьшим номером (10) — это машины куда почта должна посылаться, если это возможно. Если происходит ошибка, то почта может быть послана на машину с большим номером, вторичному почтовому серверу, например, mail.friend.bogus для которого приоритет установлен равным 20.

Перезапустите named с помощью команды ndc restart . Проверьте результаты работы используя команду nslookup:

При внимательном тестировании вы обнаружите ошибку. Строка

Я сознательно сделал ошибку, чтобы вы смогли получить некоторый опыт —:-) Глядя в файл зоны мы обнаружим, что в строке

Я должен подчеркнуть, что в файле named.conf не должно быть символа ` . ‘ после имен доменов. У вас может не быть понятия про символ ` . ‘ — это слишком часто или наоборот слишком редко заполняет разные вещи и смущает много людей.

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

Здесь присутствует несколько новых записей о ресурсах (RR): запись HINFO (Информация о машине, Host INFOrmation) имеет две части, хорошей привычкой является заключение каждой из этих частей в кавычки. Первая часть — это информация об оборудовании машины, а вторая часть описывает программное обеспечение и операционную систему данной машины. Машина, названная ‘ns’, имеет процессор Pentium и работает под управлением Linux 2.0. CNAME (Каноническое имя, Canonical NAME) — это способ присвоить каждой машине несколько имен. Так, что www является алиасом для ns.

Использование записи CNAME является немного неоднозначным. Но безопасным способом будет следовать правилу, что записи MX, CNAME или SOA никогда не должны ссылаться на имя, указанное как запись CNAME, они должны ссылаться на имя определенное записью A, так что будет неправильно записать но вместо этого необходимо записать

Также лучше считать, что запись CNAME не является настоящим именем машины для использования в адресе электронной почты: адрес webmaster@www.linux.bogus является неправильным адресом электронной почты. Вы можете ожидать, что некоторые администраторы электронной почты во внешнем мире следят за моблюдением этого правила, даже если у вас все работает нормально. Для того, чтобы избежать этого используйте запись A (и возможно также некоторые другие записи, такие как MX) вместо:

Некоторые из разработчиков архитектуры bind (arch-bind-wizards), рекомендуют не использовать запись CNAME. Так, что ее использование надо рассматривать серьезно.

Но как вы видите, этот документ также как и множество других серверов не следуют этому правилу.

Загрузите новую базу данных выполнив команду ndc reload , это заставит named перечитать файлы зон заново.

Это означает, что должны быть перечислены все записи в данном домене. В результате получится следующее:

Это хорошо. Как вы видите, это выглядит почти как сам файл зоны. Теперь проверим какой будет ответ только для машины с именем www :

Другими словами, настоящим именем для www.linux.bogus является ns.linux.bogus , и он также дается некоторая дополнительная информацию о машине ns, достаточная, чтобы соединиться с ней.

Теперь мы находимся на середине пути.

Теперь программы могут преобразовывать имена машин в домене linux.bogus в адреса, по которым они могут связаться с этими машинами. Но также, кроме этого, требуется обратная зона, которая дает возможность DNS преобразовывать адреса в имена машин. Эти имена используются достаточным количеством серверов различного рода (FTP, IRC, WWW и другими) для того, чтобы решить, хотят ли они с вами общаться или нет, и даже иногда имя машины используется для того, чтобы решить какой приоритет вам дать. Обратная зона требуется для полного доступа к различным сервисам в Internet.

Поместите следующие строки в файл named.conf :

Эти строки похожи на описание зоны 0.0.127.in-addr.arpa , а файл зоны также имеет сходное содержание:

Теперь перезапустите ваш named ( ndc restart ) и снова проверьте его работу с помощью программы nslookup:

так, это выглядит нормально, теперь выдайте полный список машин в домене, для того чтобы проверить правильность информации:

Выглядит хорошо! Если вывод вашей команды выглядит не так, то посмотрите сообщения об ошибках в вашем syslog, я объяснял как это сделать в самом начале главы.

Существует несколько вещей, которые я должен добавить здесь. Сетевые адреса, используемые здесь взяты из одного из блоков ‘личных (private) сетей’, их не разрешается публично использовать в internet. Так, что их можно спокойно использовать как пример в этом документе. Вторая вещь это строка notify no; . Она заставляет named не извещать вторичные (ведомые) сервера, когда вы обновляете один из файлов зон. В bind-8, named может уведомлять другие сервера, перечисленные в записях NS в файлах зон, когда конкретная зона обновляется. Это является удобным для обычного использования, но для личных экспериментов с зонами эта возможность должна быть отключена, мы же не хотим, чтобы наш эксперимент загрязнял internet?

И конечно, этот домен является фиктивным, также как и все адреса в нем. Для настоящего примера действующего домена смотрите следующий раздел.

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

Я буду обсуждать два сбоя обратного поиска так, как они видятся извне вашей сети:

Обратная зона не делегируется

Когда вы просите вашего сетевого провайдера о предоставлении диапазона сетевых адресов и имени домена, то имя домена обычно делегируется. Делегирование является клеем, который связывает записи NS, которые помогают вам переходить от одного сервера имен к другому, как это описывалось в теоретическом разделе. Вы прочитали его, не так ли? Если ваша обратная зона не работает, то вернитесь назад и прочитайте нужный раздел. Прямо сейчас.

Обратную зону также надо делегировать. Если вы получили от вашего провайдера сеть 192.168.196 с доменом linux.bogus , то вам необходимо поместить запись NS в вашу обратную зону, точно так же как и для прямой зоны. Если вы проследуете по цепочке с in-addr.arpa и поднимитесь до своей сети то вы скорее всего обнаружете разорванную цепочку. Скорее всего в районе вашего сетевого провайдера. Обнаружив разрыв цепочки свяжитесь с вашим сетевым провайдером и попросите его исправить ошибку.

Вы получили бесклассовую сеть.

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

Бесклассовая сеть — это то, что сохраняет работу Internet в наши дни. Несколько лет назад было много разговоров о том., что ip-номера слишком коротки. Умные люди в IETF (Internet Engineering Task Force, они сохраняют Internet в рабочем состоянии) объединились вместе и решили данную проблему. За цену. Цена заключается в том, что вы получаете подсеть меньше подсети класса «C» и некоторые вещи могут не работать. Пожалуйста посмотрите страницу Ask Mr. DNS at http://www.acmebw.com/askmrdns/00007.htm для подробного объяснения об этом и как с этим работать.

Вы прочитали эту информацию? Я ничего не буду объяснять здесь, так что пожалуйста прочитайте.

Первая часть проблемы заключается в том, что ваш провайдер должен понимать технологию, описанную Mr. DNS. Не все маленькие провайдеры имеют работающее решение данной проблемы. Если это так, то вы должны объяснить это провайдеру и быть настойчивы. Но сначала убедитесь, что вы сами это понимаете ;-). Они смогут установить правильную обратную зону на своем сервере, который вы должны проверить на работоспособность используя команду nslookup.

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

Существует другая возможность для скрытой ошибки. Старые программы разрешения имен не смогут следовать приему с CNAME в цепочке разрешения имен и буду давать сбой при выяснении имени вашей машины. В результате этого различные сервисы будут относить вас к классу неправильного доступа, запрщать доступ или делать что-то подобное. Если вы столкнулись с таким сервисом, то решение (которое я знаю) заключается только в том, чтобы ваш правайдер вставил вашу запись PTR прямо в фиктивный файл бесклассовой зоны вместо фиктивной записи CNAME.

Некоторые провайдеры будут предлагать другие способы решения этой проблемы, подобные основанным на Web формам ввода ваших записей обратной зоны или другие автоматические системы. Вперед Назад Содержание

Источник