«DNS и BIND»

6. Конфигурирование узлов

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

Итак, DNS-серверы для ваших зон заработали, и теперь необходимо настроить узлы сети таким образом, чтобы они при работе пользовались этими серверами. В частности, необходимо настроить DNS-клиенты этих узлов, для чего следует указать, каким серверам имен адресовать запросы и в каких доменах искать. Все эти темы, включая настройку клиента в распространенных вариантах системы UNIX, а также в Microsoft Windows 2000, Windows 2003 и Windows XP (которые настраиваются практически одинаково), рассмотрены в этой главе.

DNS-клиент

Мы рассказывали про DNS-клиенты в главе 2 «Как работает DNS», но без особых подробностей. Они отвечают за перевод запроса программы в запрос к DNS-серверу и за перевод ответа сервера в ответ для программы.

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

Есть одно обстоятельство, о котором следует упомянуть прямо сейчас: в следующих разделах мы будем описывать поведение обычного DNS-клиента BIND версии 8.4.6 в отсутствие других служб имен. Не все клиенты ведут себя так же; некоторые поставщики систем включают клиент, основанный на более ранних версиях кода DNS, а некоторые реализовали дополнительную функциональность, позволяющую изменить алгоритм работы клиента. В случаях, когда, по нашему мнению, это имеет значение, мы будем описывать разницу в поведении клиента BIND 8.4.6 и более ранних версий системы, в частности 4.8.3 и 4.9, которые все еще включались во многие системы на момент последнего обновления этой книги. Различные расширения мы рассмотрим позже в этой главе.

Настройка DNS-клиента

Что же именно можно настроить в DNS-клиенте? Большинство клиентов позволяют изменять по меньшей мере три аспекта поведения: локальное доменное имя, список поиска и сервер (серверы) имен, кото¬ рый (которые) опрашивает клиент. Во многих UNIX-системах для настройки доступны дополнительные аспекты поведения, что связано с наличием нестандартных расширений DNS. Иногда эти расширения необходимы, чтобы иметь дело с некоторыми программами, скажем Сетевой информационной службой Sun (NIS), а иногда они добавляются просто для увеличения стоимости системы.[1]

Настройка DNS-клиента практически полностью ограничивается редактированием файла /etc/resolv.conf (это может быть /usr/etc/resolv. conf или нечто подобное на вашем узле; более подробная информация содержится в руководстве по программе-клиенту (resolver), как правило, в разделах 4 или 5). Существует пять основных инструкций настройки, которые можно использовать в пределах resolv.conf: domain, search, nameserver, sortlist и options. Эти инструкции контролируют поведение DNS-клиента. В некоторых реализациях UNIX существуют и другие инструкции; мы рассмотрим их в конце главы.

Локальное доменное имя

Локальное доменное имя - это доменное имя, в пределах которого существует DNS-клиент. В большинстве случаев это имя совпадает с доменным именем зоны, в которой расположен узел клиента. Например, для клиента на узле toystory.movie.edu в качестве локального доменного имени, вероятно, используется movie.edu.

Клиент использует локальное доменное имя для интерпретации имен, не являющихся абсолютными. Например, при добавлении строки:

relay bernie

к файлу .rhosts имя relay считается расположенным в локальном домене. Это гораздо более логично, чем давать пользователю bernie доступ к каждому узлу сети Интернет, доменное имя которого начинается с relay. Прочие файлы авторизации, такие как hosts.equiv и hosts.lpd, также следуют этому правилу.

В обычной ситуации локальное доменное имя определяется по имени узла; локальным доменным именем считается часть имени, следующая за первой точкой « . ». Если имя не содержит точки, то в качестве локального домена принимается корневой. Таким образом, имя узла (hostname) asylum.sf.ca.us подразумевает локальное доменное имя sf.ca.us, а имя узла dogbert - корневой локальный домен, что, скорее всего, неверно, если учесть, насколько мало количество узлов с доменным именем из одной метки.[2]

Локальное доменное имя можно также установить с помощью инструкции domain в файле resolv.conf. Инструкция domain имеет для клиента более высокий приоритет, чем извлечение локального доменного имени из имени узла.

У инструкции domain очень простой синтаксис, но использовать ее следует правильно, поскольку клиент не сообщает об ошибках. Ключевое слово domain начинается в первой колонке строки, за ним может следовать один или несколько пробелов или символов табуляции. Строка завершается локальным доменным именем. Локальное доменное имя не должно заканчиваться точкой. Вот пример правильной инструкции:

domain colospgs.co.us

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

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

Какой из трех методов следует использовать? Мы изначально предпочитаем автоматическое определение локального доменного имени на основе имени узла прежде всего потому, что так принято в Беркли и этот способ более правильный - в том смысле, что минимизирует дополнительные явные настройки. Кроме того, некоторые из программ Беркли, в особенности программы, использующие библиотечный вызов ruserok() для идентификации пользователей, допускают использование кратких имен узлов в файлах типа hosts.equiv только в том случае, если полное доменное имя узла было определено посредством hostname.

Если же речь идет о программах, которые не могут работать с длинными именами узлов (hostnames), можно воспользоваться инструкцией domain. Команда hostname будет по-прежнему возвращать краткое имя, а DNS-клиент будет подставлять домен из файла resolv.conf. Использование же переменной LOCALDOMAIN может понадобиться для узла с большим числом пользователей.

Список поиска

Локальное доменное имя - производное от имени узла или заданное вфайле resolv.conf - также определяет список поиска по умолчанию. Список поиска был придуман, чтобы немного облегчить жизнь пользователям путем сокращения объема набираемого текста. Идея состоит в том, чтобы производить поиск по вводимым в командной строке неполным именам (именам, не являющимся абсолютными) в одном или нескольких доменах.

Большинство сетевых команд UNIX, принимающих доменное имя в качестве одного из аргументов (например, telnet, ftp, rlogin, rsh), используют для этого аргумента список поиска.

При переходе от BIND 4.8.3 к BIND 4.9 изменился как способ задания стандартного списка поиска, так и способ его применения. Если применяемый клиент старого образца, то мы столкнемся с поведением версии 4.8.3, а если речь идет о более новой модели, включая BIND 8.4.7 [3], то мы увидим изменения, которые появились в версии 4.9.

Независимо от версии BIND пользователь может показать, что имя является абсолютным, добавив к нему точку.[4] Так, последняя точка в команде:

% telnet ftp.ora.com.

означает «Нет смысла искать в других доменах, это доменное имя является абсолютным». Аналогичным образом работает первый слэш в полных именах файловых систем UNIX или MS-DOS. Если путевое имя начинается с символа слэша, оно интерпретируется как абсолютное и вычисляется от корня файловой системы, в противном случае оно является относительным (вычисляется от текущего каталога).

Список поиска BIND 4.9 и более поздних версий

В клиентах BIND версии 4.9 и более поздних стандартный список поиска включает только локальное доменное имя. Таким образом, если узел настроен следующим образом:

domain cv.hp.com

стандартный список поиска будет содержать только cv.hp.com. Кроме того, прежде чем воспользоваться списком поиска, клиент сначала пробует найти имя как есть; в более ранних версиях это было не так. Если в набранном аргументе есть хотя бы одна точка, клиент выполнит поиск этого имени до того, как применить список поиска. Если поиск не даст результата, дело дойдет до списка поиска. Даже если в аргументе нет точек (то есть имя состоит из одной метки), поиск в точности этого имени будет осуществлен клиентом после того, как закончатся варианты с добавлением элементов списка поиска.

Почему лучше попробовать сначала аргумент дословно? Разработчики BIND на собственном опыте убедились, что в большинстве случаев, если пользователь набирает имя, содержащее хотя бы одну точку, он с большой вероятностью набирает полное доменное имя без последней точки. Так что лучше сразу выяснить, является ли имя полным именем домена, чем создавать бессмысленные имена, добавляя метки из списка поиска.

Таким образом, если в BIND версии 4.9 или более поздней пользователь наберет:

% telnet pronto.cv.hp.com

это приведет к поиску сначала имени pronto.cv.hp.com, поскольку это имя содержит даже не одну, а целых три точки. Лишь не найдя адреса pronto.cv.hp.com, клиент попробует имя pronto.cv.hp.com.cv.hp.com. Команда

% telnet asap

выполненная на том же узле, приводит к поиску клиентом сначала имени asap.cv.hp.com, поскольку это имя («asap») не содержит точек, а затем просто имени asap.

Заметим, что перебор имен из списка поиска прекращается, как только очередное доменное имя возвращает данные, которые являлись предметом поиска. В примере с именем asap никогда бы не произошел поиск по имени asap, если бы процесс разрешения имени asap.cv.hp.com закончился получением адреса.

[1] Служба NIS раньше носила имя Yellow Pages (Желтые страницы), или YP, но была переименована, поскольку оказалось, что права владения именем Yellow Pages принадлежат телефонной компании Великобритании.
[2] На самом деле существуют отдельные имена доменов, связанные с адресами, например cc.
[3] Несмотря на добавление консорциумом ISC многочисленных новых функций к серверной части BIND 8 и 9, анализатор остался практически таким же, как в BIND 4.9.
[4] Как мы уже говорили, анализатор правильно интерпретирует точку в конце имени. Однако некоторые программы, в частности отдельные пользовательские почтовые программы, некорректно работают с почтовыми адресами, которые заканчиваются точкой. Причем ошибки начинаются раньше, чем доменное имя из поля адреса добирается до анализатора.