Команды unix справочник. Основные команды ос unix. Команды Linux для управления пользователями
В данном материале мы рассмотрим конфигурацию программы named при организации сервера домена, чьи хосты распределены по двум физическим IP-сетям класса C (в нотации CIDR x.x.x.x/24). Основное внимание будет уделено "обратным" зонам, т.к. "прямая" зона в этом случае не имеет существенных отличий от зоны, рассмотренной при описании небольшого корпоративного домена.
Ситуация, рассматриваемая в данном случае, характерна для организаций, которые имеют более одной сети класса C, где необходимо развернуть корпоративный домен. Если быть более точным, то речь идет не только о сетях класса C.
Предположим, что адресные пулы, которые выделены организации и ее подразделениям, представляют из себя не единое адресное пространство, а нарезку из нескольких блоков адресов. При этом эти блоки нарезаны таким образом, что адреса оказываются из разных областей, если рассматривать адресное пространство с точки зрения нотации CIDR х.х.х.х/24. Например:
192.168.0.0/24 и 192.168.10.0/24
С точки зрения описания соответствия между доменным именем и IP-адресом в "прямой" зоне здесь проблем нет:
$ORIGIN ru.
test IN SOA ns.test.ru. hostmaster.test.ru (
233 3600 300 9999999 3600)
;
IN NS ns.test.ru.
IN NS ns.privider.ru.
IN A 192.168.10.1
IN MX 10 mail.test.ru.
IN MX 20 mail.provider.ru.
;
ns IN A 192.168.10.1
mail IN A 192.168.0.1
www IN A 192.168.10.2
ftp IN A 192.168.0.2
Из примера видно, что адресные записи могут прекрасно "перемешиваться" в описании зоны. Таким образом, прямую зону можно определить на любом множестве наборов адресов, которые могут быть, как угодно разбросаны по адресному пространству.
Конечно, есть адреса, которые нельзя мешать. Например, нельзя мешать маршрутизируемые и немаршрутизируемые адреса. Собственно, в примере мы используем именно последние (подробнее о немаршрутизируемых адресах см. RFC 1918).
Если запросить из Интернет IP-адрес по доменному имени и в ответ получить адрес из немаршрутизируемого пула, то не понятно, что с ним делать. Даже если вы сами находитесь внутри немаршрутизируемой сети полученный снаружи адрес из этой же сети, скорее всего, не является искомым адресом.
На самом деле, один и тот же сервер доменных имен может поддерживать как маршрутизируемые соответствия, так и немаршрутизируемые, но этот случай для простоты изложения лучше оставить до отдельного разбора в другом материале.
И так, в "прямой" зоне мы можем "мешать" адреса, но вот как поддерживать обратные соответствия? Ведь в случае "обратных" зон мы имеем дело тоже с доменными именами, хотя они и образованы инверсией IP-адресов. Разделителем в иерархии именования доменов является символ ".", следовательно, границы байтов в адресе будут соответствовать границам вложенности доменов.
Выход простой - создать две обратных зоны 0.168.192.in-addr.arpa и 10.168.192.in-addr.arpa. Выглядеть это будет примерно так:
$TTL 3600
10 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.
И для 0.168.192.in-addr.arpa. соответственно:
$TTL 3600
$ORIGIN 168.192.in-addr.arpa.
0 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.
На master сервере должно быть объявлено две "обратных" зоны. В BIND 4.x в файле named.boot это будет выглядеть примерно так:
directory /etc/namedb
primary test.ru test.ru
primary localhost localhost
primary 127.in-addr.arpa localhost.rev
primary 10.168.192.in-addr.arpa 10.168.192.in-addr.arpa
primary 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa
xfrnets 192.168.20.1&255.255.255.255
cаche . named.root
options no-recursion no-fetch-glue fake-iquery
Собственно, важным с точки зрения контекста данного материала являтся наличие среди директив управления двух директив primary для соответствующих обратных зон.
Здесь стоит только пояснить, что в данном случае адрес 192.168.20.1 - это адрес slave сервера, которому разрешено копировать зону. Назначение остальных директив управления подробно рассмотрено в "Небольшой корпоративный домен в домене ru. Описание "прямых" зон. Описание "обратных" зон. Настройки BIND.".
Что же касается файла named.conf версий BIND 8.х и 9.х, то его содержание будет выглядеть примерно так:
options {
directory "/etc/namedb";
allow-query {any;};
recursion no;
fake-iquery yes;
fetch-glue no;
use-id-pool yes;
};
//Root server hints
zone "." { type hint; file "named.root"; };
// Forward Loopback
zone "localhost" {
type master;
file "localhost";
};
// Reverse Loopback
zone "0.0.127.in-addr.arpa" {
type master;
file "localhosr.rev";
};
// Corporative domain
zone "test.ru" {
type master;
file "test.ru";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "0.168.192.in-addr.arpa";
allow-transfer { 192.168.20.1; };
};
// Reverse corporative domain
zone "10.168.192.in-addr.arpa" {
type master;
file "10.168.192.in-addr.arpa";
allow-transfer { 192.168.20.1; };
};
Это описание также содержит две директивы для обратных зон, на которые отображаются имена. Описание несколько более длинное, чем для BIND 4.х в силу иного формата файла конфигурации, но суть его та же.
Здесь следует отметить, что несколько обратных зон появляются, например, и для сетей типа x.x.x.x/23. Вся штука в том, что, адресный пул, например, 192.168.0.0.23, объединяет два смежных блока 192.168.0.0/24 и 192.168.1.0/24. Соответствующих обратных зон, следовательно, будет две: 0.168.192.in-addr.arpa и 1.168.192.in-addr.arpa. Объединить их стандартным образом можно только на уровне 168.192.in-addr.arpa, но никак не ниже.
Из выше сказанного, следует, что владелец зоны 168.192.in-addr.arpa должен делегировать ответственность за управления двумя обратными зонами своему клиенту, если не хочет управлять ими самостоятельно.
Аналогичные замечания справедливы и для адресных пулов x.x.x.x/16 и для адресных пулов x.x.x.x.8, т.е. сетей классов B и A соответственно. Пространство доменных имен "обратных" зон построено с учетом старой классификации адресов, в то время, когда нотация CIDR широко еще не использовалась.
В документе RFC 1519 подробно разбирается отображение адресного пространства CIDR на "суперсети" сетей класса C, т.е. пулов адресов, которые составлены из подсетей сетей класса B и A. Провайдер в этом случае должен делегировать соответствующие обратные зоны клиентам, а те обеспечить их поддержку способом, похожим на случай 192.168.0.0/23, рассмотренный выше.
- Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
- P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (
Система доменных имён - основа современного интернета. Люди не желают затруднять себя запоминанием набора цифр 63.245.217.105, а хотят чтобы по имени mozilla.org компьютер соединил их с указанным узлом. Этим и занимаются DNS-серверы: переводят запросы людей в понятный им цифровой формат. Однако в некоторых случаях может потребоваться обратное (reverse) преобразование IP-адрес → DNS-имя. О таких именах и пойдёт речь ниже.
Для чего нужно?
Наличие корректно настроенного rDNS адреса совершенно необходимо, чтобы отправлять сообщения с вашего собственного сервера корпоративной почты . Практически все почтовые серверы отвергнут приём сообщения ещё на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удалённым почтовым сервером будет, скорее всего, указана такой:
550-"IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record."
или
550-There"s no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.
или просто
550 Your IP has no PTR Record
Число 550 во всех трёх случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая непреодолимо препятствует дальнейшей работе в рамках данной почтовой сессии. Надо сказать, что вообще все ошибки серии 500 являются критическими и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS) и в случае её отсутствия сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).
Как настроить и использовать?
Правами на настройку обратной зоны DNS (reverse DNS) обладает лишь владелец соответствующего блока IP-адресов, которой эта зона соответствует. Как правило этим владельцем оказывается провайдер, владеющий собственной автономной системой. Подробнее о регистрации своей автономной системы (AS) и блока IP-адресов можно прочитать в этой статье . Если кратко, то оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своём личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS и настроить поддержку зоны вида 3.2.1.in-addr.arpa на них. За ресурсы в обратной зоне отвечает указатель (pointer) - запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса в имя хоста.
Если же вы не являетесь счастливым обладателем автономной системы, то настройка rDNS для IP-адреса или адресов почтового сервера для вас начинается и заканчивается запросом в службу поддержки провайдера или хостера. В обоих случаях имя IP-адресу почтового сервера, а особенно корпоративного почтового сервера, следует давать осмысленно.
Примеры хороших имён для сервера почты:
mail.domain.ru
mta.domain.ru
mx.domain.ru
Примеры плохих имён:
host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru
и подобные. Такие имена с высокой вероятностью попадут под фильтр как назначенные клиентским компьютерам, на которых не может быть установлен почтовый сервер, следовательно с них рассылается спам.
С успехом использовать запросы к обратным зонам DNS можно и нужно сразу после запуска почтового сервера. Для этого необходимо произвести лишь небольшую настройку ПО. В разных почтовых серверах настройка проверки rDNS делается по-разному:
reject_unknown_client
verify = reverse_host_lookup
В оснастке Exgange Server перейти в раздел Servers далее выбрать сервер в развернутом списке, выбрать Protocols, далее протокол SMTP, в правом окне выделить SMTP сервер и по клику правой клавишей мыши выбрать из списка Properties. Далее закладка Delivery → Perform reverse DNS lookup on incoming messages
Теперь все сообщения с IP-адресов не имеющих обратной записи в DNS (записей типа PTR) будут отвергаться, поток спама, значительно сократится. Пожалуй, это самый простой, действенный и наименее ресурсоёмкий из всех методов фильтрации спама: проверкой reverse DNS отсекается подавляющее большинство спама, рассылаемого с заражённых компьютеров обычных пользователей, составляющих ботнеты спамеров.
При перепубликации статьи установка активной индексируемой гиперссылки на источник - сайт сайт обязательна!
Прямой просмотр нужен для разрешения доменных имен в ІР-адреса, обратный просмотр – для разрешения ІР-адресов в доменные имена.
В каждом сегменте сети должна быть зона обратного просмотра. В частности, если у вас есть подсети 192.168.10.0, 192.168.11.0 и 192.168.12.0, у вас должно быть три зоны обратного просмотра.
Стандартное имя зоны обратного просмотра составляется из идентификатора сети, выстроенного в обратном порядке, и суффикса in-addr.arpa. Зоны обратного просмотра из предыдущего примера будут называться 10.168.192. in-addr.arpa, 11.168.192.in-addr.arpa и 12.168.192.in-addr.arpa. Записи зон обратного и прямого просмотра должны быть синхронизированы. В случае сбоя синхронизации в домене может произойти сбой проверки подлинности.
Чтобы создать зону обратного просмотра, выполните следующие действия:
1. Откройте, консоль Диспетчер DNS (DNS Manager) и подключитесь к нужному серверу.
2. Щелкните правой кнопкой элемент сервера и выберите команду Создать новую зону (New Zone). Откроется Мастер создания новой зоны (New-Zone Wizard). Щелкните Далее (Next).
3. Если вы настраиваете основной сервер, интегрированный с Active Directory, установите переключатель Основная зона (Primary Zone) и убедитесь, что установлен флажок . Если вы не хотите интегрировать DNS в Active Directory, установите переключатель Основная зона (Primary Zone) и сбросьте флажок Сохранять зону в Active Directory (Store The Zone In Active Directory) . Щелкните Далее (Next).
4. Если вы настраиваете зону обратного просмотра для дополнительного сервера, установите переключатель Дополнительная зона (Secondary Zone) и щелкните Далее (Next).
5. Если вы интегрируете зону с Active Directory, выберите одну из следующих стратегий репликации:
Для всех DNS-серверов в этом лесу (То All DNS Servers In This Forest) Это обширнейшая стратегия репликации. Помните, что лес Active Directory включает все деревья доменов, использующие данные каталога совместно с текущим доменом.
Для всех DNS-серверов в этом домене (То All DNS Servers In This Domain) Выберите эту стратегию, чтобы реплицировать информацию DNS внутри текущего домена и его дочерних доменов.
Для всех контроллеров домена в этом домене (То All Domain Controllers In This Domain) Выберите эту стратегию, если хотите реплицировать информацию DNS на все контроллеры домена внутри текущего домена и его дочерних доменов. Хотя эта стратегия обеспечивает более широкую репликацию информации DNS внутри домена, не каждый контроллер домена является DNS-сервером (вам и не нужно настраивать каждый контроллер домена как DNS-сервер).
6. Установите переключатель Зона обратного просмотра (Reverse Lookup Zone) . Щелкните Далее (Next).
7. Укажите, для каких адресов вы хотите создать зону обратного просмотра (IPv4 или IPv6) и щелкните Далее (Next) . Выполните одно из следующих действий:
Если вы проводите настройку для IPv4, введите идентификатор сети для зоны обратного просмотра. Вводимые значения определяют стандартное имя зоны обратного просмотра. Щелкните Далее (Next).
Если вы проводите настройку для IPv6, введите префикс сети для зоны обратного просмотра. Имена зон автоматически генерируются на основе вводимых значений. В зависимости от введенного префикса вы можете создать до восьми зон. Щелкните Далее (Next).
8. Если вы настраиваете основной или дополнительный сервер, не интегрированный в Active Directory, задайте имя файла зоны. Стандартное имя файла для БД зоны DNS должно быть уже введено. Оставьте его неизменным или введите новое имя. Щелкните Далее (Next).
9. Укажите, следует ли разрешить динамические обновления. У вас есть три возможности:
Разрешить только безопасные динамические обновления (Allow Only Secure Dynamic Updates) Если зона интегрирована в Active Directory, вы можете воспользоваться списками ACL, чтобы ограничить круг клиентов, которые могут выполнять динамические обновления. Если вы установите этот переключатель, динамически обновлять записи ресурсов смогут только клиенты с учетными записями компьютеров, прошедшими проверку, и одобренными ACL.
Разрешить любые динамические обновления (Allow Both Nonsecure And Secure Dynamic Updates) Установите этот переключатель, чтобы позволить любому клиенту обновлять его записи ресурса в DNS при наличии изменений.
Запретить динамические обновления (Do Not Allow Dynamic Updates) Этот переключатель отключает динамические обновления DNS. Его следует использовать только при отсутствии интеграции зоны с Active Directory.
После установки зон обратного просмотра необходимо убедится в правильности обработки делегирования для зоны. Свяжитесь с информационным отделом или поставщиком услуг Интернета, чтобы проверить регистрацию зон в родительском домене.