Как работает DNS
Категория: Система доменных имен | Автор: admin | 10-04-2010, 02:51 | Просмотров: 2745

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

 

Делегирование

 

Все серверы имен знают о существовании корневых серверов. Последние, в свою очередь, знают о доменах "com", "org", "edu", "fi", "de" и других доменах верхнего уровня. Сервер домена "edu" знает о домене colorado.edu, сервер домена "com" знает о домене admin.com и т.д. Каждая зона может делегировать полномочия по управлению своими поддоменами другим серверам.

Рассмотрим реальный пример. Предположим, требуется узнать адрес узла vangogh.cs.berkeley.edu с машины lair.cs.colorado.edu. Компьютер lair просит свой локальный сервер имен, ns.cs.colorado.edu, найти ответ на этот вопрос. Последующие события изображены на рис. А. Мы использовали относительные имена, чтобы уменьшить неразбериху и улучшить читабельность надписей. Цифры возле стрелок определяют порядок событий, а буквы — тип транзакции (запрос, ответ или отсылка). Мы предполагаем, что перед запросом никакие из требуемых данных не кэшировались, за исключением имен и IP-адресов серверов корневого домена.

 

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

Раньше корневые серверы хранили данные как о корневых зонах, так и об общих доменах, но сегодня у последних есть свои собственные серверы имен. В ответ на запрос к корневому серверу об узле vangogh.cs.berkeley.edu мы получим ссылку на сервер домена "edu".

Локальный сервер имен посылает свой запрос к серверу домена "edu" и получает обратно ссылку на серверы домена berkeley.edu. Тогда он повторяет запрос, направляя его в домен berkeley.edu. Если сервер университета Беркли не рекурсивен и не содержит ответ в кэше, он вернет ссылку на домен cs.berkeley.edu. Сервер этого домена авторитетен в отношении запрашиваемой информации и возвращает адрес компьютера vangogh.

Когда все закончится, в кэше сервера ns.cs.colorado.edu окажется адрес компьютера vangogh. В кэше также будут списки серверов доменов "edu", berkeley.edu и cs.berkeley.edu.

Демон named посылает запросы по протоколу UDP через порт 53. Ответные пакеты также имеют формат UDP, если только их объем не превышает 512 байтов: в этом случае используется протокол TCP. В зонных пересылках всегда применяется протокол TCP.

 

Кэширование и эффективность

 

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

В течение долгого времени кэширование применялось только к положительным ответам. Если имя или адрес компьютера было невозможно найти, этот факт не фиксировался. Схема кэширования отрицательных DNS-ответов была описана в документе RFC 1034, но она оказалась неполной и осталась нереализованной в большинстве версий BIND. В 1998 г. был опубликован документ RFC2308, в котором описывалась обновленная схема отрицательного кэширования. Она была реализована в BIND 8.2 в виде опционального компонента, но в BIND 9 это уже обязательный компонент.

Измерения, проведенные на сервере RIPE в Европе, показали, что 60 % DNS-запросов относилось к несуществующим данным (многие запросы были адресованы домену 127.in-addr.arpa или содержали в качестве сетевых имен названия сервисов Microsoft). Кэшируя эту информацию как можно глубже в DNS-дереве, можно добиться резкого снижения нагрузки на корневые серверы.

При отрицательном кэшировании сохраняются ответы следующих типов

  • отсутствие узла или домена, соответствующих запрашиваемому имени;
  • данные запрашиваемого типа не существуют для указанного узла;
  • запрашиваемый сервер не отвечает;
  • сервер недоступен из-за проблем в сети.

 

Ответы первых двух типов сохраняются в кэше в течение 1—3 часов, остальные — 5 минут. Неавторитетные ответы могут кэшироваться, а авторитетные негативные ответы — обязаны.

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

Когда демону named приходится выбирать среди удаленных серверов, все из которых авторитетны для данного домена, он в первую очередь определяет период кругового обращения (round-trip time, RTT) каждого сервера. Затем серверы сортируются по "корзинам" в соответствии со значением RTT, после чего выбирается сервер из самой быстрой корзины. Серверы в пределах одной корзины считаются равнозначными и выбираются по циклической схеме.

Простейший, но весьма эффективный способ распределения нагрузки — закреплять одно имя за несколькими IP-адресами (соответствующими разным компьютерам):

www           IN      А       192.168.0.1

              IN      А       192.168.0.2

              IN      А       192.168.0.3

 

Загруженные Web-серверы, такие как Yahoo и AltaVista, в действительности не являются одной машиной. Они просто известны под одним доменным именем в DNS. Сервер имен, обнаруживший несколько записей с одинаковым именем и типом, возвращает все их клиенту, но в циклическом порядке. Например, порядок записей А в показанном выше примере будет 1, 2, 3 для первого запроса, 2, 3, 1 — для второго и 3, 1,2 — для третьего.

 

Расширенный протокол DNS

 

Исходное определение протокола DNS датируется концом 80-х гг. и предполагает использование протоколов UDP и TCP. Первый нужен для запросов и ответов, а второй — для зонных пересылок между главными и подчиненными серверами. К сожалению, максимальный размер пакета, который гарантированно принимается всеми реализациями UDP, составляет 512 байтов. Это слишком мало для новых схем обеспечения безопасности DNS, подразумевающих включение в каждый пакет цифровой подписи.

Данное ограничение влияет на число и названия корневых серверов. Чтобы все данные этих серверов умещались в 512-байтовом UDP-пакете, количество серверов ограничено числом 13, а имя каждого сервера состоит из одной буквы.

Многие распознаватели выдают сначала UDP-запрос, и если приходит усеченный ответ, то запрос повторяется в формате TCP. Эта процедура позволяет выйти за рамки 512-байтового лимита, но она неэффективна. Кое-кто может посчитать, что следует вообще отказаться от UDP и перейти исключительно на TCP, но TCP-соединения являются гораздо более дорогостоящими. Обмен данными между серверами имен в рамках протокола UDP может свестись всего к двум пакетам: один запрос и один ответ. В случае протокола TCP требуется минимум семь пакетов: трехфазовое квитирование для инициализации диалога, запрос, ответ и завершающее квитирование для разрыва соединения.

В середине 90-х гг. протокол DNS был усовершенствован механизмами инкрементных зонных пересылок (напоминает применение команды diff для сравнения старого и нового зонных файлов; прототипом послужила программа patch, написанная Ларри Уоллом), асинхронных уведомлений (для информирования подчиненных серверов об изменениях файлов главного сервера) и динамических обновлений (для DHCP-узлов). Все эти нововведения привели к расширению функциональных возможностей DNS, но они не решили фундаментальную транспортную проблему.

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


 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page