Выбор нмени домена

На некоторые имена наложено табу; это, в частности, относится к уже № взятым именам, ключевому слову AT, комбинациям имен доменов верхнего уровня (например, edu.com) и повторениям имен (например, х.х.соm). ( возможно. Вам попадались имена такого типа. Например, xinet.xinet.com — допустимое имя, но имя домена — просто xinet.com, а в нем есть машина xinet).

RFC1032 рекомендует, чтобы имена доменов второго уровня имели в длину не более 12 символов, несмотря на то, что DNS допускает использовать в каждой составляющей до 64 символов.

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

Для получения и IP-адресов нужно будет обратиться к своему Internet-провайдеру.

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

• выбор имени, уникального для данного поддомена;

• назначение двух или более машин серверами нового домена;

• согласование всего сделанного с администратором родительского мена.

Каждый новый домен определяет ветвь иерархии имен.

Компоненты системы имен BIND

В систему BIND входят три компонента:

• демон named, который отвечает на запросы;

• библиотечные подпрограммы, которые отвечают на запросы машин, используя

DNS;

• командные интерфейсы пользователь-DNS: nclookup, dig, host.

Согласно терминологии, принятой в DNS, демон типа named (или машин на которой он работает) называется сервером имен, а программа-клиент, которая обращается к нему — определителем.

named, сервер имен системы BIND

Демон named отвечает на запросы об именах машин и их IP-адресах. Если named не знает ответа на какой-либо запрос, он опрашивает другие сервера и помещает их ответы в кэш. Этот демон, кроме того, отвечает за выполнение зонных пересылок, обеспечивающих копирование данных между серверами одного домена.

Серверы имен работают по каждому домену в одном из трех режим: основном, вспомогательном и кэширующем. Режимы отличаются друг от друга двумя характеристиками: откуда поступают данные и авторитетен ли сервер для данного домена.

(Зона — это домен за вычетом своих поддоменов. Серверы имен работают именно с зонами, но часто говорится "домен", хотя подразумевается "зона".)

В каждом домене и поддомене есть один основной сервер имен. Основной сервер имен хранит на диске оригинал данных домена.

Вспомогательный сервер копирует данные своего домена с основного сервера посредством операции зонной пересылки. В домене может быть несколько вспомогательных серверов имен; обязательный минимум — один.

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

Гарантируется, что авторитетный ответ сервера имен точен; неавторитетный ответ может быть устаревшим. Тем не менее, очень высокая доля неавторитетных ответов совершенно оправданна. Основные и вспомогательные серверы авторитетны для своих доменов, но не для кэшированной информации о других доменах. Кэшируюшие серверы имен никогда не бывают авторитетными.

Даже авторитетные ответы могут быть противоречивыми, если системный администратор изменил данные основного сервера имен и забыл сообщить об этом вспомогательным серверам (или если на вспомогательные серверы изменения еще не распространены).

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

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

Поиск соответствия между именами машин и их адресами выполнялняют библиотечные подпрограммы gethostbyname и gethostbyaddr.

Система BIND поставляется со всеми современными Unix-ами.

Командный интерфейс пользователя

Команда nclookup позволяет обращаться к доменной системе имен из shell. Ее можно использовать для работы с базой данных почти так же, используют команду grep для поиска имен в файле /etc/hosts.

О том, как работает DNS

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

Для преобразования имен машин в IP-адреса программы вызывают i программу gethostbyname. Если конфигурация машины предполагает использование DNS, gethostbyname с помощью определителя DNS запрашивает адрес у сервера имен.

Серверы имен бывают рекурсивными и нерекурсивными. Нерекурсивный сервер — это ленивый, безразличный сервер. Если у него есть адрес, кэшированный из предыдущего запроса, или если он авторитетен для домена, к которому относится имя, то он даст соответствующий ответ. В противном случае вместо правильного ответа он выдает отсылку к авторитетным серверам другого домена, которые должны знать ответ. Kлиент нерекурсивного сервера должен быть готов принимать отсылки и обрабатывать их.

Рекурсивный сервер возвращает только реальные ответы и сообщения об ошибках. Он сам отслеживает отсылки, освобождая от этой обязанности] клиента. Базовая процедура разрешения запроса, по сути дела, та же; единственное отличие состоит в том, что этот сервер имен заботится об обработке отсылок, не передавая их обратно клиенту.

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

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

Рекурсия может привести к заполнению кэша второстепенной информацией. Корневые серверы и безопасные основные серверы не должны этого делать. В версиях BIND до 4.9.3 для управления рекурсией нужно было ставить "заплаты" на исходный код. В версии 4.9.3 введена опция командной строки -r, которая позволяет рекурсию выключить.

Отсылки генерируются на иерархической основе. Если сервер, например, не сможет дать адрес машины lair.cs.colorado.edu, он последовательно обратится к серверам домена cs.colorado.edu, colorado.edu, edu и корневого домена. Отсылка должна включать адреса серверов домена, на который она указывает, поэтому выбор— не произвольный; сервер должен ссылаться на тот домен, серверы которого ему уже известны. Как правило, выдается наиболее полный из известных доменов. В нашем примере был бы выдан домен cs.colorado.edu (если это возможно).

Кэши серверов имен обычно предварительно загружаются серверами корневого домена ("."), поэтому всегда можно сделать некую ссылку, даже если это будут просто слова "пойди-ка спроси у корневого сервера". Давайте рассмотрим реальный пример. Предположим, мы хотим найти адрес машины mammoth.cs.berkeley.cdu с машины lair.cs.colorado.edu. Машина lair просит выяснить ответ на этот вопрос свой локальный сервер имен, ns.cs.colorado.edu.

Мы предполагаем, что перед запросом никакие из требуемых данных не кэшировались, за исключением серверов домена edu.

Р ис. Процесс обработки запроса в DNS

Локальный сервер имен ответа на запрос не знает. Более того, он не знает ничего ни о cs.berkeley.edu, ни о berkeley.edu. Он знает некоторые серверы домена edu и, будучи рекурсивным, спрашивает edu о машине mammoth.cs-berkeley.edu.

Доменом edu управляют нерекурсивные серверы имен, поэтому вместо сообщения запрошенного адреса локальному серверу говорят: "Пойди-ка спроси у домена berkeley.edu; вот адреса серверов". Локальный сервер посылает запрос о машине mammoth серверу домена berkeley.edu.

Сервер университета в Беркли не знает ответа, но, будучи рекурсивным, направляет этот запрос серверу домена cs.berkeley.edu. Этот сервер авторитетен по запрашиваемой информации и возвращает адрес машины mammoth. Сервер домена berkeley.edu кэширует этот адрес и возвращает его серверу ns.cs.colorado.edu.

Когда пыль осядет, мы увидим, что произошли следующие изменения:

ns.cs.colorado.edu кэшировал адрес машины mammoth;

ns.cs.colorado.edu кэшировал данные о серверах домена berkeley.edu;

сервер домена berkeley.edu кэшировал адрес машины mammoth.

Запросы демона named используют протокол UDP и порт 53. Если объем ответов превышает 512 байтов, то для их доставки используется протокол TCP. В зонных пересылках между серверами также применяется протокол TCP.

Кэширование повышает эффективность поиска; кэшированный ответ почти бесплатен и, как правило, точен, так как адресно-именные соответствии меняются редко. Большинство запросов касаются локальных машин и разрешаются быстро. Пользователи невольно содействуют повышению эффективности работы серверов имен, так как многие запросы повторяются.

Кэширование обычно применяют только к положительным ответам. Eсли имя или адрес машины найти невозможно, этот факт не фиксируется.

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