Как бы вы повели себя, если бы знаменитый продукт рекламировали по телевидению таким образом: "Посетите наш Web-сервер по адресу 198.182.196.56, чтобы получить более подробную информацию..."? Успели бы вы загрузить свой ПК и войти в Internet прежде, чем забудете этот адрес? Я бы не успел...

К сожалению, человеку неподвластно так хорошо обрабатывать числа, как это делают компьютеры. Чтобы компенсировать этот человеческий недостаток, системные администраторы стали пользоваться обычными символьными именами, которыми они стали называть компьютерные системы. Для облегчения процедуры поиска компьютера в сети Internet была разработана система доменных имен DNS (Domain Name System). DNS является существенным компонентом в процессе обработки электронной почты. Для себя вы можете решить, что все вопросы, касающиеся вашего домена и электронной почты, будут в ведении провайдера услуг сети Internet. В таком случае знание подробностей о работе DNS для вас не столь критично, хотя в принципе представлять, как работает DNS, не помешает (хотя бы на случай возникновения каких-либо неполадок). В этой лекции мы рассмотрим, как появилась система доменных имен, почему она является одним из основных компонентов при обработке электронной почты и каким образом сконфигурировать сервер на базе ОС Linux в качестве клиента либо сервера DNS.

История возникновения имен хостов

В те времена, когда сеть Internet еще была небольшой (всего несколько сотен компьютеров), найти нужную машину в ней не представляло особого труда. Каждый компьютер в сети Internet хранил базу данных хостов и IP-адресов. Имена хостов в Internet могли быть каким угодно и назначались администратором, например: Fred, Barney, Acct1 и т.д. Существовал также централизованный механизм учета изменений имен хостов. Примерно раз в неделю системный администратор копировал текущую базу данных имен хостов к себе на компьютер. Конечно, эта система имела свои недостатки. При подключении нового компьютера к сети требовалось убедиться, что новое название, назначаемое хосту, еще не присвоено какой-либо другой системе. Вскоре системные администраторы поняли, что этот метод назначения имен хостов становится серьезным препятствием на пути развития сети. С ростом сети Internet расширялась и база данных имен хостов. А с расширением базы данных увеличивалось и время ее загрузки для получения обновлений и время поиска нужных имен в ней. Кроме того, все сложнее становилось определять хостам уникальное символьное имя. Что-то должно было прийти на смену базе данных имен. И это были ....

Доменные имена

Метод именования хостов, который был разработан, получил название системы доменных имен (DNS). В DNS используется иерархическая распределенная база данных, которая пришла на смену базе данных имен хостов. Теперь можно было бы сказать, что "с тех пор ни на одном компьютере не ведется база данных всех хостов сети Internet". На самом деле эта база данных распределена между различными компьютерами сети Internet, которые называются серверами DNS. Теперь один компьютер-клиент, чтобы найти другой компьютер в сети Internet, должен обратиться с запросом к ближайшему серверу DNS и получить IP-адрес удаленного компьютера. В порядке внедрения этой системы был разработан новый протокол для обмена информацией между сервером DNS и клиентом. Для серверов DNS было разработано соответствующее программное обеспечение, с помощью которого они могли обслуживать новую систему баз данных.

Структура DNS

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

Первый (или как его еще называют верхний) уровень распределения разделен на домены на основе кодов стран. Дополнительно к доменам верхнего уровня отнесены домены, созданные для различных организаций в США. Это было сделано для того, чтобы предотвратить переполнение и конфликтные ситуации в домене .us. Доменное имя добавляется в конце имени хост-компьютера и формирует уникальное имя в сети Internet для данного компьютера. Это и есть известный сегодня формат имени хоста, с которым вы, вероятно, уже сталкивались не один раз. В табл. 4.1 дается описание некоторых доменов верхнего уровня.

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

Основные условия для работы серверов DNS одной зоны — наличие отдельного соединения с сетью Internet и размещение их в различных сетях для обеспечения отказоустойчивости. Поэтому многие организации полагаются на провайдеров Internet, которые ведут в их интересах вторичные и третичные серверы DNS.

Уникальный адрес в сети Internet для данной зоны формируется добавлением к имени хоста доменного имени. Таким образом, компьютер fred в домене smallorg.org будет называться fred.smallorg.org. Постарайтесь не запутаться, так как домен может содержать как хосты, так и зоны. Например, домен smallorg.org может содержать хост fred.smallorg.org и в то же время вести зону acctg.smallorg.org, которая является поддоменом и может содержать еще один хост barney.acctg.smallorg.org. Хотя это и упрощает базу данных имен, однако делает поиск хостов в сети Internet более сложным. На рис. 4.2 показан пример домена и связанного с ним поддомена.

В системе DNS реализуются три сценария поиска IP-адреса в базе данных.

• Компьютер, которому необходимо получить соединение с другим компьютером в той же зоне, посылает запрос локальному DNS-серверу зоны на поиск IP-адреса удаленного компьютера. Локальный DNS-сервер, имеющий этот адрес в локальной базе данных имен, возвращает запрашиваемый IP-адрес компьютеру, который посылал запрос.
• Компьютер, которому необходимо получить соединение с компьютером в другой зоне запрашивает локальный DNS-сервер своей зоны. Локальный DNS-сервер обнаруживает, что нужный компьютер находится в другой зоне, и формирует запрос корневому DNS-серверу. Корневой DNS-сервер спускается по дереву серверов DNS и находит соответствующий локальный DNS-сервер. От него он получает IP-адрес запрашиваемого компьютера. Затем корневой DNS-сервер передает этот адрес локальному серверу DNS, который послал запрос. Локальный DNS-сервер возвращает IP-адрес компьютеру, с которого был подан запрос. Совместно с IP-адресом передается специальное значение — время жизни TTL (time to live). Это значение указывает локальному DNS-серверу, сколько времени он может хранить IP-адрес удаленного компьютера у себя в кэше. Благодаря этому увеличивается скорость обработки последующих запросов.
• Компьютер, которому необходимо повторно получить соединение с компьютером в другой зоне запрашивает локальный DNS-сервер своей зоны. Локальный DNS-сервер проверяет, нет ли этого имени в его кэше и не истекло ли еще значение TTL. Если адрес еще в кэше и значение TTL не истекло, то IP-адрес посылается запрашивающему компьютеру. Это считается неавторизованным ответом, так как локальный DNS-сервер считает, что с момента последнего запроса IP-адрес удаленного компьютера не изменился

Во всех трех случаях компьютеру для поиска какого-либо компьютера в сети Internet нужен лишь IP-адрес локального сервера DNS. Дальнейшую работу по поиску IP-адреса, соответствующего запрошенному имени, выполняет локальный DNS-сервер. Как видите, теперь все намного проще для локального компьютера. На рис. 4.3 показан механизм работы системы DNS.

По мере роста дерева DNS, к серверам системы доменных имен предъявлялись новые требования. Как уже упоминалось ранее, родительские DNS-серверы должны иметь IP-адреса своих дочерних серверов DNS, чтобы правильно обрабатывать DNS-запросы на преобразование имен в IP-адреса. Чтобы DNS-запросы обрабатывались правильно, поиск по дереву DNS должен начинаться из какой-то определенной точки. В период младенчества сети Internet большинство запросов на поиск имен приходилось на локальные имена хостов. Основная часть DNS-трафика проходила внутри локальной зоны и лишь в худшем случае достигала родительских серверов DNS. Однако с ростом популярности Internet и, в частности Web, все больше DNS-запросов формировалось к удаленным хостам вне локальной зоны. Когда DNS-сервер не находил имя хоста в своей базе данных, он вынужден был запрашивать удаленный DNS-сервер. Наиболее подходящими кандидатами для удаленных DNS-серверов, естественно, стали серверы DNS верхнего уровня, которые обладают полной информацией о дереве доменов и способны найти нужный DNS-сервер, ответственный за зону, к которой принадлежит запрашиваемый хост. Затем они же возвращают IP-адрес нужного хоста локальному DNS-серверу. Все это приводит к колоссальным перегрузкам корневых серверов системы DNS. К счастью, их не так много и все они равномерно распределяют нагрузку между собой. Локальные DNS-серверы работают с серверами DNS доменов верхнего уровня с помощью протокола DNS, который рассматривается далее в этой лекции.

Система DNS — улица с двусторонним движением. DNS не только отыскивает IP-адрес по заданному имени хоста, но способна выполнять и обратную операцию, т.е. по IP-адресу определять имя хоста в сети. Многие Web- и FTP-серверы в сети Internet ограничивают доступ на основе домена, к которому принадлежит обратившийся к ним клиент. Получив от клиента запрос на установку соединения, сервер передает IP-адрес клиента DNS-серверу как обратный DNS-запрос. Если клиентская зона DNS настроена правильно, то на запрос будет возвращено имя клиентского хоста, на основе которого затем принимается решение о том, допустить данного клиента на сервер или нет.

Записи в базе данных DNS

DNS-сервер, отвечающий за имена хостов в своей зоне, должен хранить информацию о хостах в базе данных и выдавать ее по запросу с удаленных компьютеров. База данных DNS представляет собой текстовый файл, состоящий из исходных записей RR (resource records). Эти записи описывают компьютеры и их функции в локальной зоне. Для организации обмена информацией с удаленными серверами DNS на сервере Linux должно быть запущено программное обеспечение сервера DNS (обычно это программа named). Чуть позже в этой лекции мы рассмотрим работу этой программы.

Прежде всего в базе данных сервера DNS должна быть объявлена зона, за которую данный сервер несет ответственность. Далее в ней должны быть объявлены все хост-компьютеры, имеющиеся в зоне. И, наконец, в базе данных можно объявлять специальную информацию, касающуюся зоны (например, о серверах электронной почты и DNS-серверах). Формат записи базы данных был разработан таким образом, чтобы DNS-сервер мог почерпнуть из нее любую информацию, нужную для его работы. В табл. 4.2 приведены основные типы исходных записей, которые могут присутствовать в базе данных DNS. База данных DNS в последнее время стала темой для дискуссий среди исследователей. Так как многие хотят дополнить ее новыми возможностями и наряду с этим повысить уровень безопасности. В настоящее время в базу данных DNS постоянно вносятся новые типы записей. В табл. 4.2 отражены лишь основные типы записей, которые необходимы для открытия и ведения новой зоны в базе данных DNS.

Каждый DNS-сервер домена должен содержать исходные записи для всех хостов этого домена. В нем должна присутствовать одна запись SOA, которая вносится в самом начале базы данных. Все остальные исходные записи могут добавляться далее в произвольном порядке. На рис. 4.4 показан пример базы данных DNS для сети с рис. 4.2. В следующем разделе основные типы записей будут рассмотрены более подробно.

Запись "начало полномочий" (SOA- Start of Authority)

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

Формат записи SOA:

Здесь domain name — имя зоны, которая далее описывается в базе данных (можно использовать также знак @ для обозначения домена по умолчанию для данного компьютера).

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

class обозначает протокол, который используется в системе (в нашем случае везде будет присутствовать класс IN для сети Internet ). Этот параметр также необязателен и по умолчанию ставится в значение IN.

origin — имя компьютера, где ведется основная зона. Будьте осторожны при расстановке разделительных точек (.)! Не забудьте поставить точку после имени хоста, иначе доменное имя будет добавлено к имени хоста (если конечно вы не хотите обратного).

person — адрес электронной почты лица, ответственного за данную зону. Здесь имеется небольшое отличие от предыдущих версий DNS. Так как значок @ уже применяется для указания домена по умолчанию, его нельзя еще раз указывать в адресе электронной почты. Вместо знака @ используйте обычную точку ".". Так, например, вместо адреса sysadm@smallorg.org используйте sysadm.smallorg.org. Если в адресе электронной почты имеются другие точки, то вместо них используйте обратную косую черту \. Например, адрес john.jones@smallorg.org будет преобразован в john\jones.smallorg.org.

serial number является уникальным числом, которое идентифицирует версию файла базы данных. Очень часто для этой цели используется дата создания файла или последней его модификации и номер версии файла (например, 200026061).

refresh — интервал времени (в секундах), по истечении которого вторичный DNS-сервер должен опрашивать первичный DNS-сервер о текущей версии записи SOA. Если версия отличается от имеющейся во вторичном сервере DNS, то он пошлет запрос на обновление своей базы данных. Обычно для этого параметра устанавливается значение 1 час (3600 секунд).

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

expire — это интервал времени (в секундах) по истечении которого вторичный DNS-сервер может использовать данные, полученные от первичного DNS-сервера, без обновлений. Обычно это значение довольно большое, например 3600000 секунд (около 42 дней).

minimum — интервал времени (в секундах), который должен использоваться как TTL для всех исходных записей в зоне. Обычно 86400 секунд (т.е. одного дня) достаточно для этого параметра.

Запись Internet-адреса (A)

Каждый хост в зоне должен иметь в базе данных запись типа А, которая определяет его имя в сети Internet. Формат записи типа А:

где host — полностью определенное имя компьютера (включая доменное имя), а address — IP-адрес этого компьютера.

Каноническое имя (CNAME)

Кроме обычного имени, некоторые хосты могут иметь два-три дополнительных имени (псевдонима). Это удобно, когда требуется идентифицировать различные сервисы. При этом нет необходимости переименовывать компьютеры в домене. Например, имя, зарезервированное для Web-сервера, — www.smallorg.org. Запись CNAME связывает псевдонимы с реальными именами хостов. Ее формат следующий:

Запись сервера имен (NS)

В каждой зоне должно быть по крайней мере два сервера DNS. Записи NS служат для их идентификации другими DNS-серверами, которые пытаются преобразовать имена хостов, относящихся к данной зоне. Формат записи NS:

domain — имя домена в зоне, за которую отвечает DNS-сервер. Если оно опущено, то NS-запись относится к зоне, указанной в записи SOA.

server — имя DNS-сервера. Для него также должна существовать соответствующая запись типа А, где будет указан его IP-адрес.

Запись с информацией о хосте (HINFO)

Дополнительную информацию о параметрах компьютера можно сделать доступной для DNS посредством объявления записи HINFO. Формат записи HINFO следующий:

host — имя хост-компьютера, к которому относится информация из записи.

hardware — краткая характеристика аппаратного обеспечения компьютера.

software — тип и номер версии операционной системы, используемой в компьютере.

Запись указателя (PTR)

Кроме записи А, для каждого компьютера в зоне создается также запись типа PTR. Это позволяет серверу DNS выполнять обратное преобразование для IP-адресов. Без этой информации удаленные серверы не смогут определить имя домена, в котором находится ваш компьютер. Формат записи PTR:

IN-ADDR name — это обратное отражение имени DNS в IP-адрес. Это, может показаться немного запутанным, но соответствует действительности. Это имя позволяет DNS-серверу работать в обратном порядке, когда преобразованию в имя подлежит IP-адрес компьютера. Адрес IN-ADDR.ARPA является специальным доменом, который поддерживает работу шлюза и преобразование Internet-адресов в имена хостов. При этом нет необходимости в обратных запросах, так как IP-адрес соответствует фиктивному имени хоста. Так, например, имя IN-ADDR name для компьютера с IP-адресом 192.168.0.1 будет 1.0.168.192.IN-ADDR.ARPA.

name в конце записи обозначает имя хост-компьютера согласно записи А.

Запись почтового сервера (MX)

Наиболее важными (по крайней мере для администраторов систем электронной почты) являются записи MX. С их помощью удаленные серверы электронной почты узнают, куда отправлять почту для вашей зоны. Формат записи типа МХ следующий:

Здесь name — имя зоны (если оно опущено, то запись относится к зоне, указанной в SOA). Можно также указывать здесь имя хоста в сети, на который вы хотели бы перенаправлять всю электронную почту.

Параметр preference — целое число, обозначающее порядок подключения, если почта принимается от нескольких почтовых серверов. Он представляет собой приоритет, на основе которого, принимается решение о предпочтительности того или иного почтового сервера. Так, значение 0 соответствует наивысшему приоритету среди почтовых серверов. Приоритет убывает с увеличением значения preference. С помощью этого параметра обычно создаются первичные и вторичные почтовые серверы для данной зоны. Когда от удаленного почтового сервера на DNS-сервер поступает запрос о почтовом сервере, ответственном за данную зону, то в ответ ему посылается список всех почтовых серверов с соответствующими им приоритетами. Удаленный почтовый сервер попытается соединиться с сервером, у которого самый высокий приоритет из списка, и, если попытка оказалась неудачной, продолжает устанавливать соединение с менее приоритетными серверами.

host — имя почтового сервера. Ему также должна соответствовать запись типа А, где будет указан его адрес IP.

Пример базы данных DNS для домена

Если вы решили не обременять себя ведением домена и почтового сервера, а отдать эти функции на откуп провайдеру Internet, то он организует поддержку соответствующих записей в своей базе DNS, представляя ваш домен в сети Internet. Запись SOA будет идентифицировать ваш домен, но указывать на хост провайдера, который будет являться авторизованным (уполномоченным) хостом. Записи NS для вашего домена также будут указывать на DNS-серверы провайдера, а в МХ-записях будут указаны почтовые серверы провайдера. Для всей остальной сети Internet в этом случае эти компьютеры являются частью вашей сети, даже если реально они к ней не относятся. В листинге 4.1 представлен пример описания зоны в базе данных DNS провайдера Internet.

В строках 1–6 показана запись SOA для вашего нового домена. Здесь провайдер указывает, что ваше доменное имя smallorg.org ведется его сервером master.isp.net. В строках 8 и 9 определяются первичный и вторичный серверы DNS, которые будут использоваться для преобразования имен ваших хост-компьютеров (заметьте, принадлежащих провайдеру). Строки 11 и 12 определяют первичный (mail1.isp.net) и вторичный (mail2.isp.net) почтовые серверы, которые будут принимать и накапливать электронную почту для вашего домена. Имя хоста www.smallorg.org — это псевдоним, указывающий на ваш Web-сервер. Адрес ftp.smallorg.org указывает на ваш FTP-сервер, который также находится на хосте провайдера. Все это элементарные услуги, предоставляемые провайдерами сети Internet тем клиентам, которые не могут позволить себе постоянное соединение с сетью Internet по выделенной линии, но желают предоставить своим клиентам Web- и FTP-сервисы. Строки 17 и 19 задают информацию об IP-адресе в сети. С ее помощью удаленные клиенты могут найти и подключиться к этому серверу через Internet. Довольно часто записи типа PTR (см. строку 19) выделяются в отдельную базу данных. Это делается с целью упрощения баз данных системы DNS. В приведенном нами примере это непринципиально, так как мы имеем дело лишь с одной записью PTR, однако часто можно встретить базы данных с дюжиной и более записей PTR.

Теперь, когда сервер DNS имеет правильно сконфигурированную базу данных, пришло время обмениваться запросами на преобразование имен хостов с другими DNS-серверами. Этот обмен DNS-запросами производится согласно специально разработанному протоколу DNS.

Протокол DNS

Протокол DNS выполняет две основные функции. Он позволяет клиентским компьютерам запрашивать DNS-сервер об IP-адресе или имени какого-либо хоста в сети, а также позволяет производить обмен информацией между базами данных серверов DNS. В этом протоколе используется стандартный формат типа "запрос-ответ", где клиент посылает пакет запроса, и сервер отвечает либо пакетом с информацией, полученной из базы данных, либо сообщением об ошибке, в котором указывается причина отказа в обработке запроса. В своей работе этот протокол использует порт 53 и хорошо известные протоколы — TCP или UDP. Причем в последнее время UDP стал более распространенным методом транспортировки пакетов по сети Internet. Пакет DNS состоит из пяти полей: заголовка, вопроса, ответа, полномочий и поля дополнительной информации. На рис. 4.5 показана общая структура пакета DNS.

Поле заголовка

В поле заголовка содержится информация о пакете и его назначении. В нем дается общее описание пакета (пакет запроса или пакет ответа) и указывается количество данных, содержащихся в каждом поле данных пакета. Описание заголовка приводится в табл. 4.3.

Биты ID являются уникальным 16-битовым идентификационным номером пакета запроса. Пакет ответа, формируемый сервером, также использует этот идентификационный номер, чтобы клиент мог сопоставить ответ сервера со своим запросом. Бит QR обозначает тип пакета (пакет запроса — 0, пакет ответа — 1). Поле OPCODE определяет тип запроса — стандартный (0), обратный (1) или запрос о статусе сервера (2).

Следующие четыре бита определяют различные параметры пакета. Бит AA устанавливается, когда ответ является авторитетным (данные поступают напрямую от DNS-сервера, ответственного за зону). Неавторитетные ответы могут поступать от серверов DNS, в кэше которых сохранилась информация об исходных записях от предыдущих запросов. Эта информация считается неавторитетной, так как есть вероятность, что с момента последнего обращения к серверу информация была изменена. Бит TC устанавливается, когда требуется урезать данные в пакете до вида, удобного для передачи по сети. Такое вполне возможно при использовании протокола UDP, согласно которому размер пакета не должен превышать 512 байт. Бит RD включается, когда клиент желает рекурсивно запрашивать DNS-сервер на постоянной основе. Если этот бит установлен, то DNS-сервер будет запрашивать другие DNS-серверы, пока не получит ответ. Если этот бит не установлен, то DNS-сервер будет возвращать на запрос любую информацию, которая у него имеется. Бит RA устанавливается, чтобы уведомить клиента о возможности рекурсивного запроса на данный сервер. Биты Z в настоящее время не используются и зарезервированы на будущее.

Биты RCODE используются только в пакетах ответов. Они отображают состояние ответа — без ошибок (0), ошибки в пакете запроса (1), внутренние ошибки не дали возможности серверу обработать запрос (2), имя, указанное в запросе, не существует (3), данный тип запроса не поддерживается сервером (4) и сервер отказался обработать запрос (5).

Остальные четыре параметра заголовка представляют собой 16-битовые числа и используются в качестве счетчиков. С их помощью ведется учет количества исходных записей, возвращаемых в пакете. QDCOUNT отображает количество запросов (в пакет может включаться более одного запроса). ANCOUNT — количество исходных записей, включенных в ответ. NSCOUNT обозначает число исходных записей об авторитетных серверах имен, а ARCOUNT — число записей в поле дополнительной информации.

Поле вопроса

Поле вопроса содержит запросы, ответы на которые клиент желает получить от DNS-сервера. В одном пакете DNS может содержаться несколько запросов. Количество запросов в пакете определяется параметром QDCOUNT из поля заголовка. Поле вопроса состоит из трех частей: списка преобразуемых доменных имен; поля типов записей, которые клиент желает получить в ответе, и параметра класса запроса. Список преобразуемых доменных имен представляет собой список имен, для которых клиент желает получить IP-адреса. Для формирования списка имен используется специальный формат. Перед каждым именем ставится однобайтное значение, которое определяет длину имени. Конец списка обозначается именем с нулевой длиной. После текстовой части следует двубайтная запись QTYPE. В ней определяется, в каком виде клиент желает принимать информацию о имеющихся доменах. Эти значения полностью соответствуют типам исходных записей в DNS. Например, для того чтобы найти почтовый сервер для определенного домена, вам следует воспользоваться типом записи МХ. И, наконец, последний параметр в поле вопроса — QCLASS. Он определяет класс запроса, который в нашем случае для сети Internet всегда будет IN.

Поля ответа, полномочий и дополнительной информации

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

Например, если запросить информацию об МХ-записях домена, то в поле ответа будет получена информация об МХ-записях, а в поле дополнительной информации — записи А для серверов, указанных в поле ответа. Таким образом, с помощью одного DNS-запроса можно узнать и имя, и IP-адрес почтового сервера для домена.

Формат представления исходной записи в пакете DNS показан в табл. 4.4.

В поле ответа значения RDATA соответствуют результатам обработки запроса. Записи МХ представляются не в текстовом формате. Вместе с именем почтового сервера в них вносится значение приоритета.

Сокращение имен

Если в качестве ответов возвращается несколько записей, может возникнуть дублирование текстовых данных. Такая ситуация возникает, например, при возвращении двух записей типа NS — ns1.isp.net и ns2.isp.net. Эффективнее было бы просто возвращать ответ ns1 и ns2 в домене isp.net. Для уменьшения размера пакета во время DNS-запроса в протоколе DNS реализован метод сокращения передаваемой информации по вышеописанному принципу. Этот метод был разработан для устранения дублирования доменной информации. Для отслеживания дублированной информации была разработана система указателей. Как уже отмечалось ранее, первым в разделе имени является байт, определяющий длину доменного имени. Для сокращения имен значения двух старших бит в нем были изменены. Если эти биты оба равны 0, то байт длины по-прежнему отвечает только за длину доменного имени. Если же оба этих бита равны 1, то значение байта становится указателем смещения в разделе имен, которое указывает на остаток доменного имени, подсоединяемый к имени хоста.

DNS и электронная почта

Чтобы правильно доставить почту компьютеры должны следовать определенному алгоритму. Знание этого алгоритма пригодится при решении проблем в работе электронной почты. Когда удаленный клиент посылает электронное сообщение по адресу prez@smallorg.org, перед его отправкой происходит следующее.

• Локальный DNS-сервер клиента сначала должен определить, на какой компьютер в домене smallorg.org можно отсылать электронную почту. Решение об этом он принимает на основе МХ-записей, полученных для домена smallorg.org.
• Если в базе данных или кэше имен локального DNS-сервера не содержится никакой информации об этом домене, то он должен сформировать запрос в Internet и искать ответ там. Прежде всего он попытается получить эту информацию от одного из DNS-серверов верхнего уровня. Естественно, в нем не будет информации о записи МХ для вашего домена, но он определенно получит сведения о DNS-сервере, в ведении которого находится домен .org.
• Этот сервер, в свою очередь, также не будет иметь информации о ваших МХ-записях и т.п., но он должен иметь IP-адрес DNS-сервера для домена smallorg.org и запросить его о соответствующих МХ-записях. Если имеется одна и более записей МХ для данного домена, то все они отсылаются в порядке следования клиенту, от которого поступил запрос.
• Теперь, когда клиент обладает IP-адресом (или адресами), он пытается установить SMTP-соединение (см. лекцию 5, "Протокол SMTP") с главным почтовым сервером домена smallorg.org.
• Если это соединение установить не удалось, то клиент будет устанавливать соединение по протоколу SMTP со вторичным почтовым сервером, и так далее, пока соединение не будет установлено или не останется серверов, к которым он может обратиться. С этого момента все дальнейшие действия зависят от почтовой программы у клиента. Большинство почтовых программ попытаются повторить весь процесс установки соединения спустя несколько часов. Они будут пытаться повторить этот процесс указанное число раз, после чего делают заключение о невозможности доставки почты.

Если база данных DNS сконфигурирована неправильно, то в поисках ответственного за доставку почты в вашем домене хоста DNS может прервать поиски и вернуть клиенту ответ с сообщением об ошибке. Помните, что сама система DNS не участвует в доставке сообщений электронной почты. Цель DNS — предоставление удаленному клиенту IP-адреса, компьютера который способен принимать и обрабатывать электронную почту в домене smallorg.org. Получив этот IP-адрес, удаленный клиент может инициировать почтовый сеанс по протоколу SMTP.

ОС Linux как клиент DNS

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

Если же ваш почтовый сервер имеет постоянное соединение с Internet, но вы хотите, чтобы провайдер содержал все записи о вашем домене, то, сконфигурировав свой почтовый сервер, можно добиться того, что он будет использовать DNS-сервер провайдера для преобразования имен в IP-адреса. Ниже описаны способы конфигурирования сервера на базе ОС Linux для реализации этого решения.

Конфигурирование клиентских файлов DNS

Для организации работы вашего Linux-сервера в качестве клиента системы DNS понадобится три файла. Обычно все они находятся в каталоге /etc. Это файлы resolv.conf, hosts и host.conf.

Файл преобразования имен хостов

Файл /etc/resolv.conf используется для указания Linux-серверу, какому DNS-серверу должны направляться DNS-запросы. Здесь можно указать до трех DNS-серверов. Второй и третий серверы из списка будут использоваться в качестве резервных, если ответ не будет получен от первого (главного) сервера. Если в вашей сети имеется локальный DNS-сервер, то его нужно использовать в качестве главного. Если в локальной сети доступ организован на базе имен компьютеров, то это значительно увеличит скорость доступа, так как преобразование имен хостов в адреса через локальный DNS-сервер происходит быстрее. Если же DNS используется для доступа к удаленным компьютерам вне сети, то не следует ожидать повышения скорости доступа. Кроме того, в этом файле можно указать имя домена по умолчанию для ускорения поиска доменов системой DNS. Например, можно указать начало поиска доменов с домена smallorg.org как с домена по умолчанию. Теперь, если нужно получить IP-адрес для хоста fred.smallorg.org, можно просто указать имя хоста fred, и ОС Linux будет автоматически добавлять к нему имя домена smallorg.org. К сожалению, это может работать и против вас. Дело в том, что система DNS будет добавлять имя домена smallorg.org ко всем хостам, для которых она производит преобразование имен. Так, если осуществляется соединение с узлом www.linux.org, сначала ведется поиск узла www.linux.org.smallorg.org. Если найти его не удалось, то производится поиск уже www.linux.org. В листинге 4.2 показан пример файла /etc/resolv.conf для клиента DNS на базе ОС Linux.

В строке 1 задается поиск домена по умолчанию, который следует использовать во всех DNS-запросах. Помните, что это может замедлить обработку запросов для хостов, не принадлежащих к вашему домену, так как текст по команде search будет добавляться ко всем запросам. В строках 2–4 указаны главный, вторичный и третичный DNS-серверы, которые обслуживают данного клиента. Наиболее часто в их роли выступают DNS-серверы провайдера, назначаемые для вашей сети, хотя вполне возможно использование и других DNS-серверов по желанию (если, конечно, ваш провайдер не фильтрует DNS-запросы).

Файл hosts

Еще один метод преобразования имен заключается в использовании локальной базы данных имен хостов, подобно тому, как это делалось на заре сети Internet. Файл /etc/hosts содержит список имен хостов с соответствующими IP-адресами. В листинге 4.3 приводится пример файла /etc/hosts для клиента на базе ОС Linux. В нем должны содержаться имя вашей машины и ее IP-адрес, а также IP-адрес петли 127.0.0.1 для служебных целей. Кроме того, если имеются какие-либо удаленные хосты, к которым периодически подключается ваш сервер на ОС Linux, их IP-адреса также желательно указать в файле /etc/hosts. Теперь при каждом обращении к этим хостам у Linux-сервера уже будут их IP-адреса; таким образом, необходимость в выполнении DNS-запросов отпадает. К тому же это намного ускоряет установление соединения.

В первой и второй строках указываются IP-адреса для локального Linux-сервера. В строках 3–5 представлены IP-адреса для наиболее часто запрашиваемых машин вашей сети. Благодаря этому ускоряется доступ к ним c сервера на базе ОС Linux, по сравнению с использованием системы DNS.

Файл преобразования DNS

В файле /etc/host.conf определяются методы и порядок преобразования имен ОС Linux. В листинге 4.4 показан пример файла /etc/host.conf.

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

Утилиты клиента DNS в ОС Linux

В помощь системному администратору для ОС Linux было написано множество утилит, призванных облегчить для DNS поиск информации об удаленных хостах и сетях. Для UNIX-систем организацией Internet Software Consortium был создан программный пакет Berkeley Internet Name Domain (BIND), в который вошли три наиболее полезные, с точки зрения автора, и широко используемые утилиты: host, nslookup и dig. Эти программы распространяются совместно с программным обеспечением, входящим в большинство дистрибутивов ОС Linux. В Red Hat и Mandrake Linux эти программы поставляются в виде пакетов RPM.

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

Утилита host

Программа host производит простейшее преобразование имени с помощью DNS. Формат команды host следующий:

По умолчанию команда host пытается получить IP-адрес для имени, указанного как host, с помощью DNS-сервера, определенного в файле /etc/resolv.conf. Если в командной строке указан server, то по умолчанию команда host будет использовать его в качестве DNS-сервера. Добавляя дополнительные параметры в командной строке, можно модифицировать работу команды host. Все эти параметры указаны в табл. 4.5.

Параметр -l может использоваться для поиска информации обо всех хостах в домене. Очень часто вместе с ним используется параметр -t для того, чтобы отфильтровать информацию по типу (например, -t MX возвращает только записи МХ для домена). К сожалению, в настоящее время из соображений безопасности использование параметра -l затруднено, так как большинство DNS-серверов отказывает в предоставлении информации о хостах из своих баз данных. Если же информация запрашивается от удаленного или загруженного DNS-сервера (или через низкоскоростное соединение), то можно использовать параметр -w. С его помощью программа host принудительно ожидает ответа на запрос. По умолчанию время ожидания составляет около минуты.

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

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

По умолчанию команда host попытается вывести результаты своей работы в удобном для чтения формате. Например, как это показано в листинге 4.5. Если же задана опция -v, то вывод имеет вид исходных записей DNS. При отладке работы системы DNS это может оказаться полезным.

В строке 1 показан основной формат команды host — просто добавьте имя хоста, о котором требуется получить информацию. Строки 2–5 представляют собой результаты работы команды. Строка 2 показывает, что DNS-сервер смог преобразовать имя заданного хоста в его IP-адрес. Далее в строках 3-5 показаны три компьютера, которые могут принимать электронную почту для заданного хоста согласно записям МХ. Заметим, что команда host показывает даже весовые коэффициенты (или приоритеты) для каждого почтового сервера. Если почта была послана пользователю указанного хоста, то сначала ее доставкой займется сервер с приоритетом 10 (mail.linux.org). Если же команда host не выполняется, то можно послать запрос через другой DNS-сервер, указав его адрес после адреса хоста в командной строке. Это весьма эффективно, если вы считаете, что локальный DNS-сервер ведет себя не совсем правильно.

Утилита nslookup

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

Если в командной строке задать параметр host-to-find, то nslookup будет работать в неинтерактивном режиме и возвратит ответ на запрос примерно в том же виде, что и утилита host. Если аргументы не заданы или первый аргумент — дефис (-), то nslookup будет работать в интерактивном режиме. При необходимости с помощью аргумента -server можно указать другой DNS-сервер, где server — IP-адрес запрашиваемого DNS-сервера. В противном случае nslookup будет по умолчанию обращаться к DNS-серверу, который задается в файле /etc/resolv.conf.

Параметры nslookup можно изменить тремя способами. Во-первых, можно задать параметры в командной строке вместе с командой nslookup. Во-вторых, можно указать их в интерактивной командной строке nslookup с помощью команды set. И в-третьих, можно создать в своем рабочем каталоге $HOME файл .nslookuprc и указать в нем желаемые параметры, по одному на строку. Список параметров, которые можно использовать с командой nslookup, приведен в табл. 4.6.

В листинге 4.6 показан пример сеанса nslookup, во время которого запрашивается информация о хосте www.linux.org. На запрос с установленными по умолчанию параметрами для указанного имени просто возвращается соответствующий ему IP-адрес. В нашем примере демонстрируется изменение параметров с целью поиска почтовых серверов для данного домена.

В строке 5 формируется запрос для хоста с именем www.linux.org. В строках 6 и 7 показан DNS-сервер, который обрабатывает данный запрос, а в строках 9–11 отображается, что сервер выдает неавторитетный ответ об IP-адресе. Очевидно, что кто-то уже обращался к этому же хосту и его IP-адрес хранился в кэше локального DNS-сервера. В строке 13 устанавливается параметр, с помощью которого запрашивается информация о почтовых серверах для данного домена. В строках 18–30 отображается информация, полученная от DNS-сервера. Строки 18–21 являются по сути разделом ответа пакета DNS, который сигнализирует о том, что ответ не является авторитетным, и далее показывает три почтовых сервера, ответственных за доставку электронной почты на хост www.linux.org. В строках 23–30 показан авторитетный ответ и дополнительная информация из пакета DNS. Так, строки 23–25 показывают два авторитетных DNS-сервера для домена linux.org, в которых содержаться исходные записи о www.linux.org. В строках 26–30 отображается дополнительная информация об IP-адресах хостов, содержащихся в ответах. Этот пример можно немного расширить, установив в качестве DNS-сервера по умолчанию один из авторитетных серверов (с помощью команды server) и запросив еще раз информацию об МХ записях. Теперь сравните, отличается ли полученная информация от той же, но выданной неавторитетным DNS-сервером.

Утилита dig

Программа dig использует обычную командную строку для формирования запросов о доменах DNS-серверам. Формат команды dig следующий:

Здесь server — необязательное имя DNS-сервера. По умолчанию в dig будет использоваться DNS-сервер, указанный в файле /etc/resolv.conf. Можно указать опцию server либо по имени хоста, либо через его IP-адрес. Если для опции server используется имя хоста, то для преобразования его в IP-адрес dig воспользуется DNS-сервером по умолчанию и будет его использовать далее для получения информации о домене.

Параметр query-type — тип исходной записи, который можно указать в запросе (A, SOA, NS и MX). Для получения всей информации о домене можно указать query-type any.

Параметр query-class — класс сетевой информации, который также можно указывать в запросе. По умолчанию этот параметр всегда будет IN для сети Internet.

Параметр +query-option используется для изменения значения параметра в пакете DNS или для изменения формата вывода результатов работы dig. Большинство этих параметров пересекаются с параметрами программы nslookup. В табл. 4.7 показаны параметры, которые можно использовать в запросе с dig.

Параметр -dig-otion используется для задания других опций, влияющих на работу dig. В табл. 4.8 представлены опции, с помощью которых можно влиять на результаты работы dig.

Пример сеанса работы dig показан в листинге 4.7. Из него видно, что программа dig выдает практически ту же информацию, что и host, и nslookup, но выводит больше данных о том, откуда и каким образом были получены ответы.

ОС Linux в качестве сервера DNS

Если имеется постоянное соединение с Internet, то, возможно, вы пожелаете содержать для своего домена собственный DNS-сервер. Это можно осуществить средствами ОС Linux. Кроме того, можно использовать сервер на базе ОС Linux как DNS-сервер в режиме кэширования. Таким образом можно добиться некоторого сокращения времени обработки DNS-запросов, так как локальный сервер на ОС Linux может поддерживать кэширование имен. Это позволяет использовать данные из кэша для ответа на последующие DNS-запросы (в рамках заданного TTL).

Как уже упоминалось, популярный программный пакет системы DNS для UNIX систем — Berkeley Internet Name Domain (BIND), разработанный Internet Software Consortium, содержит также реализацию сервера DNS. Программа, реализующая функции сервера DNS называется named. В большинство версий ОС Linux программа named входит в качестве стандартного бинарного программного пакета. Текущая версия Red Hat 6.0 использует для установки named и сопутствующих конфигурационных файлов программный пакет bind-8.2-6.i386.rpm. Если у вас нет бинарного программного пакета или вы хотите использовать последнюю версию BIND, то можно получить ее исходный код из Internet Software Consortium по адресу ftp.isc.org. Текущая версия на момент написания книги была BIND 8.2.1. Для ее установки нужно иметь инсталлированный на сервере с ОС Linux компилятор GCC, с помощью которого затем можно установить новое программное обеспечение.

Компиляция BIND

В настоящее время исходный код программного пакета BIND можно получить в виде отдельного файла с FTP-сервера ftp://ftp.isc.org/src/8.2.1/bind-src.tar.gz. Для компиляции новой программы named нужно выполнить следующие шаги.

• Распаковать полученный файл в рабочем каталоге с помощью команды
  tar -zxvf bind-src.tar.gz.
• Перейти во вновь созданный каталог src.
• Задать команду make clean.
• Задать команду make depend.
• Для создания двоичных файлов задать make.
• Задать команду make install, которая помещает двоичные и конфигурационные файлы в соответствующие каталоги.

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

Использование named в качестве кэширующего сервера

Проще всего настроить named для работы в качестве локального кэширующего сервера для хранения ответов на DNS-запросы. Для этого сначала необходимо сконфигурировать /etc/named.conf на локальном компьютере под управлением ОС Linux. В листинге 4.8 показан файл /etc/named.conf, сконфигурированный для кэширующего DNS-сервера.

В строках 1–3 определяются опции, которые используются программой named. Строка 2 показывает, что для конфигурационных файлов каталог по умолчанию — /var/named. Строки 5–7 описывают определение для корневых доменов. Как уже отмечалось ранее, каждый DNS-сервер должен содержать адреса корневых DNS-серверов, чтобы иметь возможность направлять запросы в иерархию серверов DNS. В строке 7 указывается файл содержащий адреса корневых серверов, это файл /var/named/root.cache. Этот файл можно создать с помощью команды dig:

В листинге 4.9 представлен пример файла /var/named/root.cache.

В строках 26–38 показаны IP-адреса корневых серверов DNS по состоянию на июнь 1999 года. Вам следует обновлять этот файл (через каждые 5 недель, 5 дней и 16 часов согласно значениям TTL), чтобы быть уверенным в том, что ваш DNS-сервер направляет DNS-запросы соответствующим корневым серверам.

В файле /etc/named.conf (листинг 4.8) можно указать две зоны, за которые будет отвечать ваш DNS-сервер. При этом в каждой зоне должен вестись свой файл описания. Строки 10–13 указывают на описание для зоны localhost. Эта зона описывается в файле /var/named/pri/localhost (см. листинг 4.10).

Как видно из листинга 4.10 в файле localhost задается запись SOA для сервера на ОС Linux, которая говорит о том, что это ваш локальный DNS-сервер (строка 9) и задает в качестве IP-адреса адрес локальной петли (строка 11). В конце файла /etc/named.conf описывается реверсивная (обратная) зона для локального сервера. В строках 17–19 листинга 4.8 описывается зона 0.0.127.in-addr.arpa и дается ссылка на файл конфигурации /var/named/pri/127.0.0, который подробно описан в листинге 4.11.

В строке 11 листинга 4.11 адрес петли определяется 127.0.0.1 как адрес для localhost.

И последнее, что потребуется сделать, — изменить файл /etc/resolv.conf таким образом, чтобы он указывал на локальный сервер на базе ОС Linux. Если указать в качестве главного сервера имен петлю с IP-адресом 127.0.0.1, то ОС Linux будет посылать запросы самому себе для преобразования имен в адреса. На этом завершается настройка DNS для рабочей станции. Обработка DNS-запросов в ОС Linux начинается с момента, когда в фоновом режиме запускается процесс named и в памяти организуется кэширование этих запросов.

Применение named в качестве DNS-сервера для зоны

В следующем примере представлено применение сервера на базе ОС Linux в качестве полнофункционального DNS-сервера для поддержки вашего собственного домена. Для организации его работы используются те же файлы, которые были рассмотрены в предыдущем примере, но добавляются две дополнительные зоны в файл /etc/named.conf, как показано в листинге 4.8. Новые зоны будут описывать ваш домен для программы named. Ниже, в листинге 4.12 показаны дополнительные строки, которые нужно ввести в файл /etc/named.conf.

Как и в предыдущем примере, разделы с описанием зоны определяют тип зоны, поддерживаемый DNS-сервером (master или primary), и файлы, которые его описывают. Пример файла с описанием зоны smallorg.org приведен в листинге 4.13.

Итак, вы уже на полпути ко вводу в эксплуатацию своего домена. После этого еще понадобится создать файл с базой данных DNS с реверсивными (обратными) адресами, как указано в файле /etc/named.conf (см. листинг 4.12). Ниже, в листинге 4.14 приведен пример такого файла.

Все эти конфигурационные файлы позволяют программе named правильно обрабатывать DNS-запросы в вашем домене. Конечно, при условии, что домен соответствующим образом зарегистрирован в Internet Network Information Center (InterNIC) и обслуживается соответствующими корневыми DNS-серверами верхнего уровня (в нашем случае для домена .org).

Резюме

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