Мой адрес не дом и не улица...
Система доменных имен Internet — ключевая служба, на которую замыкаются адреса информационных ресурсов, а точнее их идентификаторы Uniform Resource Identifier [1]. Как отмечено в [2], документе, посвященном роли системы доменных имен, архитектура DNS оставалась неизменной с момента своего создания, в то время как ее функции существенно изменились: коммерциализация Сети привела к существенному «уплощению» иерархии доменных имен. Владельцы ресурсов предпочитают использовать домены второго уровня в рамках национальных доменов или доменов общего назначения (например, microsoft.com), а не закапываться вглубь иерархии имен. Кроме того, начиная с 90-х годов, DNS стали использовать в качестве инструмента балансировки нагрузки серверов информационных ресурсов, эксплуатируя для этого алгоритм Round Robin, который применяется серверами доменных имен при ответе на запросы клиентов. Ни первое, ни второе при проектировании системы доменных имен не предполагалось (во всяком случае, в основополагающих документах [3] и [4] этого не указано).
Напомним типовую схему поиска IP-адреса по доменному имени.
Браузер через механизм resolver обращается к локальному кэширующему серверу доменных имен с рекурсивным запросом. Этому серверу передается доменное имя, для которого нужно найти IP-адрес. Сам браузер IP-адрес не ищет, а перепоручает это локальному кэширующему серверу доменных имен; в этом может убедиться каждый, кто сам настраивал подключение своего компьютера к Сети. При подключении через провайдера, например, по коммутируемому соединению, этого делать не нужно: сеть настраивается в большинстве случаев автоматически (в момент автоматической настройки провайдер по протоколу PPP присылает IP-адреса серверов доменных имен, которые будут выполнять рекурсивные запросы пользователя).
На схеме (см. рис. 1) указаны два типа запросов: рекурсивный и нерекурсивный. В первом случае клиент перепоручает поиск IP-адреса серверу, а втором — сам производит опрос серверов. Локальный кэширующий сервер самостоятельно опрашивает все серверы доменных имен; поэтому он обменивается с ними нерекурсивными запросами.
В системе доменных имен установлена жесткая иерархия. Начинается она с корня. Затем следуют домены верхнего уровня (Top Level Domain, TLD), например, .com, .org, .net, .ru и т.п. Далее следуют домены второго уровня, например, nic.ru, vesti.ru и т.п. Каждый домен поддерживается авторитарным сервером домена и, как правило, не одним. При этом сервер, поддерживающий старшие имена, имеет возможность перепоручить управление младшими именами другому серверу. Такое перепоручение отражается в описании домена, управляемом сервером, и называется делегированием. Та часть дерева иерархи имен, которой управляет сервер, называется зоной. Если серверу поручено управлять корнем дерева имен, и он перепоручил все TLD другим серверам, то в его ведении остается только управление соответствиями между именами доменов и именами серверов, которым он эти домены перепоручил.
Кому поручено управление младшими именами, знает только тот сервер, который осуществляет делегирование. Поэтому, когда мы ищем что-то в домене RU, мы сначала должны узнать, кто поддерживает домен RU, а затем — кто поддерживает ту часть домена RU, которая, собственно, и интересует нас. На первый вопрос отвечает корневой сервер, который обслуживает «корень» имен DNS. Таких серверов 13 — десять в США, два в Европе и один в Японии. (До сих пор такое размещение было оправданным; действительно, согласно данным [5] около 60% клиентов корневых серверов размещены в США.) На второй вопрос ответят серверы, поддерживающие национальный домен RU. Их шесть: три размещены в России и три в Европе. Кстати, согласно статистике Фонда «Общественное мнение» [6], 19% пользователей Рунета находятся в Москве — там же, где расположены и три российских сервера зоны RU. С точки зрения использования DNS правильнее ориентироваться на данные SpyLog, которые получены на основе агрегирования статистики его счетчиков, размещенных на Web-сайтах: в апреле 2003 года в Москве находилось 43% всех городских пользователей Рунета [7].
После получения ответа с сервера, поддерживающего национальный домен, мы можем обратиться к авторитативному (authorative) серверу домена, которому принадлежит интересующее нас имя. Авторитативным этот сервер называют по той причине, что именно ему делегировано право отвечать на запросы к именам из этого домена. По правилам делегирования доменов второго уровня в RU для каждого домена таких серверов должно быть не менее двух. Вообще говоря, их может быть и больше; в [8] рекомендуется иметь три. Нарушением регламента регистрации доменов, способным повлечь временную приостановку делегирования, является ситуация, когда суммарное время отсутствия связи с сервером превышает два часа за сутки [9]. Ели домен обеспечен тремя серверами, то вероятность отказа сразу на двух серверах меньше, чем на одном, что существенно понижает риск временной потери делегирования. На самом деле, локальный кэширующий сервер доменных имен обращается к корневым серверам и авторитативным серверам домена RU только тогда, когда не может найти необходимый ему адрес в своем кэше.
Время хранения соответствий в кэше сервера определяется параметром TTL (Time To Live), которое устанавливает администратор соответствующего домена. Например, значение TTL для имен авторитативных серверов домена RU равно 86400 секунд (т.е. одни сутки); другими словами, после первого обращения за адресом из домена RU локальный кэширующий сервер доменных имен может обратиться к корневому серверу за получением списка авторитативных серверов домена RU только через сутки. Аналогичная схема работает и для всех остальных доменов. Если один пользователь обратился, скажем, к www.yandex.ru через локальный кэширующий сервер провайдера коммутируемого доступа, то этот сервер будет обслуживать всех остальных пользователей этого провайдера в течение суток, не обращаясь ни к корневым серверам доменных имен, ни к авторитативным серверам домена RU. Но, если в качестве примера выбрать www.rambler.ru, то такое кэширование (по данным на июнь 2003 года) будет осуществляться только один час. А для mail.ru это время будет равно двум часам. Таким образом, для конкретного пользователя DNS время отклика будет варьироваться от времени полного опроса всех серверов, обслуживающих искомый адрес, начиная от корневого сервера и кончая авторитативным сервером поддомена, до времени опроса только своего локального кэширующего сервера.
Вернемся к вопросу о времени отклика на запрос, а точнее к параметру RTT (Round Trip Time), который обычно и используют в качестве основы различных метрик в расчетах эффективности размещения ресурсов [5].
