«DNS и BIND»

2. Как работает DNS

Клиенты DNS

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

• Опрашивание DNS-серверов
• Интерпретация полученных ответов (RR-записей или сообщений об ошибках)
• Возврат информации в программу, которая ее запросила

В пакете BIND клиент - это просто набор библиотечных процедур, которые вызываются из таких программ, как ssh и ftp. Клиент - это даже не отдельный процесс. Клиент практически во всем полагается на DNS-серверы: его хватает ровно на то, чтобы создать запрос, отправить его и ждать ответа, затем повторно послать запрос, если ответ не получен; и это практически все, на что он способен. Большая часть работы, связанной с поиском ответа на вопрос, ложится на сервер имен. Спецификация DNS называет этот тип анализатора примитивным (stub resolver).

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

Разрешение имен

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

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

Корневые DNS-серверы

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

Корневые серверы, очевидно, имеют очень большое значение для процесса разрешения имен. Поэтому в DNS существуют механизмы (скажем, кэширование, которое мы обсудим чуть позже), позволяющие разгрузить корневые серверы. Но в отсутствие другой информации разрешение должно начинаться с корневых DNS-серверов. И это делает корневые серверы ключевым элементом работы DNS. Недоступность всех корневых DNS-серверов сети Интернет в течение длительного времени привела бы к невозможности разрешения имен в сети. Чтобы исключить подобные ситуации, в сети Интернет существует (на момент написания этой книги) тринадцать корневых серверов, расположенных в различных частях сети1 . Один из них находится в сети PSINet, коммерческой информационной магистрали Интернета, один в научной сети NASA, два в Европе, а один в Японии.

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

Несмотря на такую нагрузку, разрешение имен в сети Интернет работает вполне надежно. На рис.2.12 показан процесс разрешения для адреса реального узла в реальном домене с учетом того, как производится обход дерева пространства доменных имен.

Локальный DNS-сервер запрашивает адрес girigiri.gbrmpa.gov.au у корневого сервера и получает ссылку на DNS-серверы домена au. Локальный сервер повторяет запрос, отправляя его одному из DNS-серверов au, и получает ссылку на серверы gov.au. DNS-сервер gov.au отсылает локальный DNS-сервер к серверам gbrmpa.gov.au. И наконец, локальный DNS-сервер запрашивает DNS-сервер gbrmpa.gov.au и получает искомый адрес.

Рекурсия

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

Рис.2.12 Разрешение имени girigiri.gbrmpa.gov.au в сети Интернет

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

Итерация, или итеративное разрешение имен, - это название последовательности действий DNS-сервера при получении им итеративного запроса.

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

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

DNS-сервер, получивший рекурсивный запрос, на который он сам не в состоянии ответить, отправляет запрос «ближайшим известным» серверам. Ближайшие известные серверы - это те, которые являются авторитетными для зоны, ближе всего расположенной к доменному имени, о котором идет речь. К примеру, если сервер получает рекурсивный запрос для адреса доменного имени girigiri.gbrmpa.gov.au, он, прежде всего, выяснит, известно ли, какие серверы являются авторитетными для girigiri.gbrmpa.gov.au, и, если это известно, отправит запрос одному из них. В противном случае будет произведен аналогичный поиск DNS-серверов для gbrmpa.gov.au, а затем для gov.au и au. По умолчанию поиск не будет продолжаться дальше корневой зоны, поскольку каждому DNS-серверу известны доменные имена и адреса корневых серверов имен.

Использование ближайших известных DNS-серверов позволяет во всех случаях максимально сократить процесс разрешения. Если DNS-cервер berkeley.edu получает рекурсивный запрос адреса для waxwing. ce.berkeley.edu, он не будет опрашивать корневые серверы, а использует информацию о делегировании и отправится за данными прямо к DNS-серверам ce.berkeley.edu. Точно так же сервер, который только что производил поиск адреса для доменного имени в ce.berkeley.edu, не будет начинать поиск с корня, если необходимо повторить процедуру для ce.berkeley.edu (или для berkeley.edu); причины этого мы опишем чуть позже в разделе «Кэширование».

Сервер DNS, получающий рекурсивный запрос от DNS-клиента, при поиске повторяет этот запрос в точности так, как он получен от клиента. В случае рекурсивного запроса адреса для waxwing.ce.berkeley.edu сервером никогда не будет отправлен явный запрос на информацию о DNS-серверах ce.berkeley.edu или berkeley.edu, несмотря на то, что эта информация также хранится в пространстве имен. Прямые запросы могут приводить к осложнениям: DNS-серверы ce.berkeley.edu могут не существовать (то есть ce.berkeley.edu может являться частью зоны berkeley. edu). Помимо этого вполне возможно, что сервер имен edu или berkeley.edu уже знает адрес waxwing.ce.berkeley.edu. Прямой запрос оDNS-серверах berkeley.edu или ce.berkeley.edu не приведет к получению этой информации.

Итеративное взаимодействие

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

Выбор авторитетного DNS-сервера

Некоторые из читателей (состоящие в обществе Менса1), возможно, задаются вопросом: каким образом сервер, получивший рекурсивный запрос, выбирает DNS-сервер из списка авторитетных? Мы говорили о том, что существует 13 корневых DNS-серверов в сети Интернет. Посылает ли наш DNS-сервер запрос первому из серверов в списке? Или выбирает позицию в списке случайно?

DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитетных DNS-серверов одной зоны. Время отклика определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз при передаче запроса удаленному серверу DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если серверу приходится выбирать один из нескольких авторитетных серверов, выбор падает на сервер с наименьшим временем отклика.

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

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

Картина в целом

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

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

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

Отображение адресов в имена

До сих пор в разговоре о процессе разрешения мы не затрагивали один важный элемент функциональности, а именно - отображение адресов в имена доменов. Отображение адрес-имя необходимо для получения вывода, который легко воспринимается людьми (скажем, при чтении log-файлов). Это отображение также применяется в авторизации. Например, UNIX-узлы преобразуют адреса в доменные имена с целью сравнения их с записями в файлах .rhosts и hosts.equiv. При использовании таблиц узлов отображение адресов в доменные имена довольно тривиально. Требуется обычный последовательный поиск адреса в таблице узлов. Поиск возвращает указанное в таблице официальное имя узла. Но в DNS преобразование адреса в имя происходит несколько сложнее. Данные, в том числе и адреса, которые хранятся в пространстве доменных имен, индексируются по именам. Если есть доменное имя, поиск адреса - процедура относительно простая. Но поиск доменного имени, которому соответствует заданный адрес, казалось бы, потребует полного перебора данных для всех доменных имен дерева.

Рис.2.13 Процесс разрешения

На деле же существует другое решение, более разумное и эффективное. Несложно производить поиск по доменным именам, поскольку они являются своеобразными индексами базы данных, и точно таким же образом можно создать сектор пространства доменных имен, в котором в качестве меток будут использоваться адреса. В пространстве доменных имен сети Интернет таким свойством обладает домен in-addr.arpa.

Узлам домена in-addr.arpa в качестве меток присваиваются числа в нотации IP-адреса (dotted octet representation - октеты, разделенные точками, - распространенный метод записи 32-битных IP-адресов в виде четырех чисел, принадлежащих интервалу от 0 до 255 и разделяемых точками). Так, домен in-addr.arpa может содержать до 256 поддоме- нов, каждый из которых будет соответствовать одному из возможных значений первого октета IP-адреса. Каждый из этих поддоменов может содержать до 256 собственных поддоменов, каждый из которых будет соответствовать одному из возможных значений второго октета.

Рис.2.14 Домен in-addr.arpa

Наконец, на четвертом уровне существуют RR-записи, ассоциированные с последним октетом, которые содержат полное доменное имя узла по данному IP-адресу. Результатом подобных построений является невероятно объемный домен: in-addr.arpa, отображенный на рис.2.14, достаточно вместительный, чтобы охватить все IP-адреса сети Интернет.

Заметим, что при чтении в доменном имени IP-адрес оказывается записанным наоборот, поскольку имя читается от листа дерева к корню. К примеру, если IP-адрес узла winnie.corp.hp.com - 15.16.192.152, соответствующий узел в домене in-addr.arpa - 152.192.16.15.in-addr.arpa, который отображается в доменное имя winnie.corp.hp.com.

IP-адреса могли бы быть представлены в пространстве имен другим способом так, чтобы первый октет IP-адреса был дальше от корня домена in-addr.arpa. Тогда в доменном имени IP-адрес читался бы в «правильном» направлении. Однако IP-адреса, как и доменные имена, образуют иерархию. Сетевые номера выделяются почти так же, как и доменные имена, и администраторы вольны разделять «свое» адресное пространство на подсети и делегировать нумерацию в сети другим администраторам. Разница заключается в том, что конкретизация узла для IP-адреса возрастает при чтении слева направо, тогда как для доменных имен - справа налево. Суть этого явления отражена на рис.2.15.

Рис. 2.15 Иерархия имен и адресов

То, что первые октеты IP-адреса расположены выше в дереве, позволяет администраторам делегировать ответственность за зоны in-addr.arpa в соответствии с топологией сети. Возьмем для примера зону 15.inaddr. arpa, которая содержит данные обратного преобразования для всех узлов, адреса которых начинаются с цифры 15: эта зона может быть делегирована администраторам сети 15/8. Это стало бы невозможным, если бы октеты были расположены в обратном порядке. Если бы IP-адреса записывались наоборот (в другом порядке), зона 15.inaddr. arpa включала бы каждый узел, IP-адрес которого заканчивается цифрой 15, и делегировать эту зону было бы немыслимо.