Сервер доменных имен linux

Серверы 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 почтового сервера из целевого домена.

Источник

Linux в домене Active Directory

Перед администраторами иногда встают задачи интеграции Linux серверов и рабочих станций в среду домена Active Directory. Обычно требуется:
1. Предоставить доступ к сервисам на Linux сервере пользователям домена.
2. Пустить на Linux сервер администраторов под своими доменными учётными данными.
3. Настроить вход на Linux рабочую станцию для пользователей домена, причём желательно, чтобы они могли при этом вкусить все прелести SSO (Я, например, не очень люблю часто вводить свой длинный-предлинный пароль).

Обычно для предоставления Linux системе пользователей и групп из домена Active Directory используют winbind либо настраивают библиотеки nss для работы с контроллером домена Active Directory по LDAP протоколу. Но сегодня мы пойдём иным путём: будем использовать PowerBroker Identity Services (Продукт известен также под именем Likewise).

Установка.

Есть две версии продукта: Enterprise и Open. Мне для реализации моих задач хватило Open версии, поэтому всё написанное далее будет касаться её.
Получить Open версию можно на сайте производителя, но ссылку Вам предоставят в обмен на Ваше имя, название компании и e-mail.
Существуют 32-х и 64-х пакеты в форматах rpm и deb. (А также пакеты для OS X, AIX, FreeBSD, SOlaris, HP-UX)
Исходники (Open edition) доступны в git репозирории: git://source.pbis.beyondtrust.com/pbis.git
Я устанавливал PBIS на Debian Wheezy amd64:

Содержимое пакета устанавливается в /opt/pbis. Также в системе появляется новый runscript lwsmd, который собственно запускает агента PBIS.
В систему добавляется модуль PAM pap_lsass.so.
Утилиты (большей частью консольные), необходимые для функционирования PBIS, а также облегчающие жизнь администратору размещаются в /opt/pbis/bin

Ввод в домен.

Перед вводом в домен следует убедиться, что контроллеры домена доступы и доменные имена корректно разворачиваются в ip. (Иначе следует настроить resolv.conf)
Для ввода в домен предназначены две команды: /opt/pbis/bin/domainjoin-cli и /opt/pbis/bin/domainjoin-gui. Одна из них работает в командной строке, вторая использует libgtk для отображения графического интерфеса.
Для ввода в домен потребуется указать: имя домена, логин и пароль доменного пользователя с правами для ввода ПК в домен, контейнер для размещения объекта компьютера в домене — всё то же самое, что и при вводе в домен windows ПК.

После ввода в домен потребуется перезагрузка.
Обратите внимание — PBIS умеет работать с сайтами Active Directory. Клиент PBIS будет работать с контроллерами того сайта, в котором он находится!

После перезагрузки.

После перезагрузки и id, и getent выдадут вам пользователей и группы домена (национальные символы обрабатываются корректно. Пробелы заменяются на символ «^»).
В доменной DNS зоне появится запись с именем вашего ПК.
Не спешите входить от имени доменного пользователя. Сначала имеет смысл (но вовсе не обязательно) настроить PBIS.

Одно из отличий Enterprise версии — возможность управлять этими настройками через GPO.
Стоит обратить внимание на HomeDirPrefix, HomeDirTemplate.
Я также сразу задал «RequireMembershipOf» — только пользователи, члены групп или SID из этого списка могут авторизоваться на компьютеры.
Описание каждого параметра можно получить, например так:

Значение параметра устанавливается например так:

Обратите внимание — PBIS не использует атрибуты SFU либо иные другие атрибуты Acrive Directory для получения loginShell пользователя, а также его uid и gid.
loginShell для доменных пользователей задаётся в настройках PBIS, причём установка различных loginShell различным пользователям — возможна только в Enterprise версии.
uid формируется как хэш SID пользователя.
gid — как хэш SID primaryGroup пользователя.
Таким образом на двух ПК пользователь получит всегда одинаковые uid и gid.

Теперь можно входить в систему от имени доменного пользователя. После входа доменного пользователя обратите внимание на вывод klist — PBIS получит для пользователя необходимые билеты kerberos. После этого можно безпроблемно обращаться к ресурсам на windows ПК (Главное, чтобы используемое ПО поддерживало GSSAPI). Например: теперь я без дополнительных запросов паролей (и пароль мой нигде не сохранён!) открываю любые smb ресурсы домена в Dolphin. Также Firefox (при настройке network.negotiate-auth.trusted-uris) позволяет использовать SSO при доступе к Web-порталам с доменной авторизацией (естественно если SSO настроена на сервере)

А как же SSO при доступе к ресурсам на Linux ПК?

Можно и так! PBIS заполняет /etc/krb5.keytab и поддерживает его актуальным. Поэтому серверное ПО с поддержкой GSSAPI может быть сконфигурировано для SSO.
Например, для доступа к серверу по ssh, в конфигурационный файл /etc/ssh/sshd_config (путь в вашей системе может отличаться)
И при подключении указать доменное имя компьютера (присутствующее в его SPN — иначе билет kerberos не сможет быть выписан)
UsePAM yes

(PBIS предоставляет модуль для PAM в том числе)
Также логично будет добавить директиву «AllowGroups» и указать через пробел доменные группы, пользователям которых вы намерены дать доступ к ssh серверу.

На клиентском Linux ПК в конфигурацию клиента ssh достаточно включить:

Естественно на клиентском Linux компьютере должен быть настроен kerberos. Простейший способ выполнить это условие — так же ввести клиентский компьютер в домен и работать от имени доменного пользователя.

На клиентском Windows ПК (члене домена) при использовании Putty следует в свойствах SSH соединения установить флаг «Attempt GSSAPI authentification (SSH-2 only)» (В разных версиях этот пункт называется по-разному).

Также в секции Connection —> Data можно поставить переключатель в позицию «Use system username»

Если вы намереваетесь организовать таким образом ssh доступ администраторов к linux серверам — хорошей идеей будет запретить на них вход root по ssh и добавить linux-администраторов (а ещё лучше их доменную группу) в файл sudoers.

Это не единственные сценарии применения PBIS. если статья покажется Вам интересной — в следующей напишу как организовать samba файловый сервер в домене для доменных пользователей без winbind.

Дополнительную информацию по теме можно получить на форуме сообщества PowerBroker Identity Services: forum.beyondtrust.com

UPD. К преимуществам PowerBroker Identity Services я могу отнести:

1. Хорошую повторяемость (сравните последовательность действий этой статье с инструкцией по настройке winbind)
2. Кэширование данных из каталога (доменный пользователь может войти на ПК, когда домен не доступен, если его учётные данные в кэше)
3. Для PBIS не требуется формирование в каталоге AD дополнительных атрибутов пользователя
4. PBIS понимает сайты AD и работает с контроллерами своего сайта.
5. Большую безопасность (samba создаёт учётку компьютера с не истекающим паролем)
6. В платной версии (если возникнет такая необходимость) PBIS агент управляем через GPO (хотя это можно и вычеркнуть. если вы не намерены её покупать)

UPD 2 Пришла обратная связь от пользователя sdemon72. Возможно кому-то будет полезно.

Здравствуйте! Попробовал ваш рецепт на свежей linuxmint-18-mate-64bit, все получилось с некоторыми оговорками:
1. С получением программы через сайт у меня возникли сложности (не захотел писать реальный номер телефона, а бутафорский не прокатил — пришло письмо с сомнениями по его поводу), зато нашел репозиторий с наисвежайшими версиями: repo.pbis.beyondtrust.com/apt.html
2. При запуске программы выдает ошибки, чтобы их избежать, нужно перед запуском сделать следующее:
2.1. Установить ssh:
sudo apt-get install ssh
2.2. Поправить /etc/nsswitch.conf:
hosts: files dns mdns4_minimal [NOTFOUND=return]
(т.е. переносим dns с конца строки на вторую позицию)
2.3. Поправить /etc/NetworkManager/NetworkManager.conf:
#dns=dnsmasq
(т.е. комментируем эту строчку)
2.4. Перезапустить network-manager:
sudo service network-manager restart

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

Если интересно — история моих изысканий тут: linuxforum.ru/topic/40209

С уважением, Дмитрий

UPD 3: Почему бесплатную версию PBIS не получится применить в большой компании
В бесплатной версии работает только один алгоритм генерации UNIX iD (uid и gid) по SID доменного пользователя. Так вот он не обеспечивает уникальности
этих идентификаторов. Когда у вас очень старый домен или просто много пользователей очень высок риск, что два и более пользователя получат одинаковые идентификаторы в системе с OpenPBIS. В платной версии есть возможность выбора между алгоритмами генерации id, но она стоит значительно дороже аналогичного продукта от Quest Software ;(.

Источник