Практическая реализация DNS
Общий принцип работы системы доменных имен (DNS) понятен и довольно прост. Поэтому предполагается, что Вы уже знакомы с доменами, зонами и подобными терминами и понимаете, как они работают. Хотелось бы сосредоточиться на практической реализации протокола, с точки зрения администратора, использующего сетевые мониторы, или программиста. Примеры кода, иллюстрирующие работу протокола, приведены на Java, но легко могут быть перенесены на другой язык.
Клиент отправляет UDP(TCP) пакет на порт 53 сервера с запросом отобразить имя ресурса в IP адрес (или наоборот). На сервер возлагается задача произвести работу по нахождению запрашиваемой информации. Работа по нахождению данной информации сводится к рекурсивным или итеративным запросам, но, в любом случае, работа скрыта от клиента: стандартный клиент ожидает либо ответа, либо ошибки.
В данной статье описывается процесс работы DNS с точки зрения программиста, разрабатывающего клиента или сервер.
Исходя из следующих предпосылок, приводится дальнейшее описание: клиент с сервером обращаются по протоколу UDP, где клиентом является OS Windows. Операционные системы от Microsoft работают с небольшими отличиями от стандартной схемы - это незаметно для пользователя, но важно для администратора. Связанно это с ориентировкой на работу в рамках доменов. Каждый компьютер имеет имя и принадлежит определенному домену, как, например, на рис. 1.
[ZEBR_TAG_p align="center"> рис. 1. Полное имя ресурса computer.office.acme.com.
Когда возникает необходимость в разрешении имени, работает следующая схема:
Нам надо узнать IP адрес сайта "www.yahoo.com" (без точки в конце). Компьютер клиента автоматически добавит имя домена, к которому принадлежит компьютер, т.е. на самом деле DNS запрос будет содержать имя: "www.yahoo.com.office.acme.com.".
Корпоративный сервер, ответственный за зону office.acme.com, не сможет найти ответ и возвратит клиенту ошибку, после чего сразу переспросит сервер "www.yahoo.com.". Сервер уже сможет обработать этот запрос и дать нужный или нужные IP адреса.
Для того, чтобы сервер не прибавлял суффикс достаточно в конце имени добавить точку. Кроме того, если запрос не содержит точки, например "user1", то выполняется добавление суффикса, а без него запроса не последует.
В настройках TCP/IP можно указать дополнительные суффиксы.
Стоит заметить, что полное имя ресурса должно заканчиваться точкой (www.yahoo.com.), но это правило только для пользователей, в самих сетевых пакетах финальная точка в явном виде отсутствует.
Начнем с общего формата пакета: он одинаков и для запросов, и для ответов.
Первые два байта являются идентификатором. Это числа, по которым клиент может определить, на какой из его вопросов пришел ответ, и, кроме того, обеспечивает минимальную страховку того, что ответ получен из достоверного источника.
Сервер должен скопировать идентификатор в ответ, без этого пакет просто будет отброшен клиентом.
Следующие два байта это флаги.
| Кол-во бит | ||
| Тип сообщения | 1 | QR |
| Код операции | 4 | Opcode |
| Авторитетный ответ | 1 | AA |
| Фрагментация | 1 | TC |
| Требование рекурсии | 1 | RD |
| Возможность рекурсии | 1 | RA |
| Нулевое поле | 3 | |
| Код возврата | 4 | Rcode |
Код операции: это ноль для обычного запроса и 1 для инверсного.
Авторитетный ответ устанавливается сервером, ответственным за зону.
Фрагментация устанавливается, если информация не уместилась в 512 байт.
Требование рекурсии, как правило, всегда установлено, что переносит всю ответственность за разрешение с клиента на сервер.
Возможность рекурсии устанавливается сервером в ответе.
Код возврата ноль в случае успеха и 3 при ошибке имени.
Остальные варианты опций описаны в RFC 1035, но для реализации простой схемы диалога сервера с клиентом они не требуются.
Далее следуют четыре 2х байтовых поля, которые содержат количество значений в полях с переменными длинами. Вместе с байтами идентификации и флагами они составляют заголовок DNS пакета.
Схематично заголовок выглядит следующим образом:
| 0 | 15 |
| Идентификация | |
| Флаги | |
| Количество вопросов | |
| Количество ответов | |
| Кол-во прав доступа | |
| Кол-во дополнительной инф. |
Общая длина заголовка - 12 байт, после которого следуют поля переменной длины. Нас будут интересовать только секции вопросов и ответов. В пакете от клиента количество вопросов, как правило, равно единице. А в пакете от сервера количество ответов как минимум один. Остальные счетчики будем устанавливать в ноль.
Обе секции (вопросы и ответы) имеют одинаковое начало: переменное количество байт, отведенное на имя, два байта на тип, и два - на класс. Класс будет всегда единицей. Типы - A, NS, MX, CNAME и т.д. Например, для типа A поле будет установлено в единицу, а для MX - 15. Для запросов и ответов имя кодируется одинаково. Все символы представляются своими ASCII кодами за исключением точек. Точки разделяют имя на части, а сами заменяются длинами этих частей. Для примера: www.yahoo.com.
Будет представлено в виде последовательности байт: 3www5yahoo3com0 - буквы представляются кодами.
При этом финальный ноль является обязательным, т.к. является маркером конца имени.
Теперь у нас есть достаточно информации, чтобы составить клиентский пакет, который запрашивает IP адрес хоста "aaa."
byte[] question={2,34,1,0,0,1,0,0,0,0,0,0,3,97,97,97,0,0,1,0,1};
2,34 - это идентификаторы, выбранные случайным образом
За ними следуют два байта флагов, которые сообщают о том, что это стандартный запрос, требующий рекурсию.
Следующие два байта - это кол-во вопросов, т.е. один. При этом остальных полей переменной длины нет.
Вопрос начинается сразу после заголовка - 12й байт, считая с нуля.
Такую же последовательность, за исключением идентификатора, можно увидеть сетевым монитором, сформировав запрос "aaa" с помощью утилиты nslookup.
В общем случае, сервер, приняв подобный пакет, должен выделить имя и тип.
//получение текста имени из вопроса int i=12; String s=""; String QUESTION;
while (data[i]>0) { if (s.length()>0) {s+=".";} if ((data[i]+i+1)>=len) {s="";break;} s += new String(data, i+1, data[i]); i+=data[i]+1; } QUESTION = s;
Далее сервер реализует поиск имени по собственной базе или отправляет запрос другому серверу, но в любом случае он должен сформировать ответ для клиента.
Секция ответа состоит из полей имени ресурса, типа и класса, описанных выше. При этом их содержание можно полностью скопировать из запроса. За ними следуют четыре байта поля TTL (time-to-live), содержащее количество секунд, на которое можно кэшировать запрос (заполняем нулями). Следующие два байта - это длина данных ресурса, и сами ресурсы. В ресурс помещается информация об ответе. Как указывается в RFC 1035, она зависит от типа запроса, но в нашем случае это будут четыре байта под IP адрес.
Приведем пример ответа на предыдущий запрос:
byte[] reply={2,34,133,128,0,0,0,1,0,0,0,0,3,97,97,97,0,0,1,0,1,0,0,0,0,0,4,5,6,7,8};
Тут количество вопросов - ноль, ответов - один. И ответ устанавливает соответствие имени хоста "aaa." с IP адресом 5.6.7.8 и TTL равным 0.
Стоит обратить внимание на флаги: 133 - авторитетный ответ, 128 - сервер поддерживает рекурсию.
В качестве завершающего примера приведу код сервера, который принимает DNS пакет и генерирует ответ. При этом вне зависимости оттого, что спросит клиент, ответ будет содержать "aaa" и IP адрес 5.6.7.8
После компиляции проверить это можно при помощи утилиты nslookup
import java.net.*; import java.io.*;
class udptest {
public static void main(String arg[]) { byte id1,id2,flags; int qtype;
try { byte[] buffer = new byte[512]; DatagramPacket incoming = new DatagramPacket(buffer, buffer.length); DatagramSocket ds = new DatagramSocket(53); ds.receive(incoming); byte[] data = incoming.getData(); id1=data[0]; id2=data[1]; int i=12; String s="";
while (data[i]>0) { if (s.length()>0) {s+=".";} s += new String(data, i+1, data[i]); i+=data[i]+1; } i++; byte[] reply={0,0,0,0,0,0,0,1,0,0,0,0,3,97,97,97,0,0,1,0,1,0,0,0,0,0,4,5,6,7,8}; reply[0]=id1; reply[1]=id2; reply[2]=0&133; reply[3]=0;
DatagramPacket out = new DatagramPacket(reply,reply.length, incoming.getAddress(), incoming.getPort());
ds.send(out); } catch (IOException e) {System.err.println(e);} }//main
}//class
Что такое хорошо, и что такое плохо...
Какое время отклика DNS-сервера принято считать «хорошим», а какое «плохим»? Посмотрим на наиболее загруженные и критичные с точки зрения всей системы серверы — корневые и те, что обслуживают «национальные» домены.
За последние два года был проведен ряд исследований в этой области. В CIADA [5] изучали время отклика корневых серверов на запросы клиентов со всего земного шара. Время отклика признавалось большим, если превышало 90% точку распределения времени отклика. Типичным большим временем отклика в этом исследовании было время, превышающее полсекунды. Для России из 437 точек только 14 имели большое время отклика (3% от общего числа российских участников), что сравнимо с данными по Бразилии. Важно также, что за полгода, в течение которого проводились эти исследования, доля точек в России с большим откликом не изменилась (к примеру, в Украине она увеличилась вдвое); была отмечена общая тенденция к сокращению времени отклика.
Более точные измерения проведены в работе [16]. Если в CIADA измерялось RTT от серверов к опрашивающим их хостам, то здесь использовалась программа, которая, будучи установленной в различных точках Сети и измеряла непосредственно отклик корневых серверов и серверов национальных доменов. Согласно данным [16], для США и Европы характерным временем отклика является время, меньшее 0,2 с. Здесь следует сделать оговорку. Основной объем трафика DNS приходится на корневой A–сервер; поэтому именно время отклика этого сервера и является определяющим, а оно при прямом подключении в редких случаях превышает 0,2 с. Как правило, время отклика ccTLD-серверов несколько хуже, чем корневых — несколько десятых долей секунды. Например, для Парижа среднее время отклика A-сервера равно 0,18 с, а сервера национального домена FR — 0,25 с.
А какое время отклика имеют серверы, поддерживающие домены в зоне RU? Для этого было решено замерять время обращения за записью зоны SOA (Start Of Authority), для которой сервер является авторитативным, проверять авторитативность отклика и запоминать параметр RTT. Измерения проводились из точки, для которой значение RTT до ns.ripn.net было равно 0,0013 с (запрос SOA для зоны RU), т.е. фактически от авторитативного сервера зоны RU (см. рис. 2).
Согласно статистике Ru-center, на момент проведения измерений в зоне RU было 28106 серверов [17], которые поддерживали домены второго уровня. Это означает, что 48% серверов имели время отклика менее 0,1 секунды. Еще 12% попадали в интервал 0,1-0,2 с. Приемлемое время отклика до 1 секунды имело 79% серверов; во время до 5 секунд укладывался 81% серверов.
Интересно посмотреть на 10 самых медленных (таблица 1) и самых быстрых (таблица 2) серверов из 50 наиболее популярных (по числу поддерживаемых ими уникальных доменов в зоне RU).
Разница между самыми быстрыми и самыми медленными наиболее популярными серверами составляет в среднем порядок. Пять с слишком секунд для ns1.masterhost.ru (два порядка величины) выглядят на этом фоне, мягко говоря, странно.
Следует учитывать тот факт, что серверы, поддерживающие домены второго уровня в зоне RU, как и во всем мире [18], в большинстве случаев (70%) одновременно являются и серверами, которые выполняют рекурсивные запросы. Чем ближе данный сервер расположен к корневому серверу, тем больше времени из интервала «приемлемого времени» останется на передачу полезной информации, а не на накладные расходы, к которым относится и служба DNS.
Конечно, можно возразить, что важно не как близко ты находишься к корню, а как близко к своим клиентам. Действительно, время отклика кэшируется, и не за каждым адресом приходится обращаться к авторитативному серверу доменных имен. Но больше половины пользователей, собственно, и располагаются около авторитативных серверов зоны RU, что показывает распределение времени отклика серверов доменов второго уровня.
Есть еще один момент. Например, rambler.ru, как уже было указано, кэшируется только час, а время доступа до него от ns.ripn.net — 0,004 с. Для mail.ru время доступа от ns.ripn.ru также равняется 0,004 с. Время определяется не только физическим расстоянием, но и качеством, и пропускной способностью канала. Например, для сервера ns.nsk.ru время отклика составляет 0,18 с, а для ns.spb.su — 0,019 с. В таких условиях времена отклика серверов доменных имен провайдеров услуг хостинга, которые превышают 0,15 с, выглядят плохо. Понятно, что это, скорее всего дублирующие серверы (secondary), но алгоритмы выбора серверов resolver предполагают «одинаковость» авторитативных серверов доменов.
 |
Рис. 2. Распределение времени отклика серверов доменов второго уровня в зоне RU |
Как правильно разместить DNS-сервер
Павел Храмцов
18.09.2003
Требование соблюдения заданного времени отклика и обеспечения предусмотренной в соглашении об уровне обслуживания надежности, делает весьма актуальным вопрос о размещении серверов доменных имен в Сети.
Среди ИТ-специалистов все более популярным сегодня становится вопрос разработки систем распространения контента (content distribution system), на успех работы которых очень влияет размещение информационных серверов. Речь идет о таком размещении серверов, при котором время доступа было бы если не минимальным, то хотя бы приемлемым, т.е. отвечающим соглашению об уровне обслуживания (service level agreement — SLA). Фактически, требуется в единицу времени обслужить максимальное число пользователей при заданном времени обслуживания каждого. Так, для Web-страниц таким ограничивающим фактором будет приемлемое время загрузки страницы браузером, которое складывается не только из времени передачи данных по сети и времени их интерпретации, но также и времени, затраченного на поиск IP-адреса сервера, в том числе, и из времени обращения к службе Системы Доменных Имен (DNS).
Мой адрес не дом и не улица...
Система доменных имен 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].
Не думай о секундах свысока...
Итак, как добиться приемлемого для пользователя времени обработки запроса? Прежде чем ответить на этот вопрос, разберемся, чему может быть равно это время.
Как показывают исследования [10, 11], все зависит от того, какую задачу решает пользователь. При этом обычно исследуют либо время задержки, которое начинает вызывать раздражение, либо влияние времени задержки на эффективность работы в целом. Обычно время задержки загрузки Web-страницы свыше секунды вызывает дискомфорт; однако если пользователь знает, что он получит, то раздражения не вызывают и задержки до 5 секунд. После 30 секунд речь уже не может идти об интерактивной работе. В целом для работы с известным интерфейсом подходит следующая шкала: до 5 секунд — «хорошо»; до 10 секунд — «удовлетворительно»; более 10 секунд — «плохо». Однако если показывать элементы страницы по мере их получения, то шкала для времени полной загрузки страницы изменится: до 39 секунд — «хорошо»; до 56 секунд — «удовлетворительно»; более 56 секунд — «плохо». Любопытно и другое — непреодолимое желание «ускорить» процесс возникает в среднем после 8,6 секунд ожидания хоть какого-нибудь результата.
С приемлемостью времени загрузки до 5 секунд согласны и «художники» баннеров, рекомендуя стандартный размер баннера в 10-15 Кбайт [12]: именно столько удается передать при коммутируемом соединении со скоростью 28,8 кбит/c за 3-5 секунд. (На самом деле не стоит надеяться, что пользователь, зашедший на ваш сайт впервые, будет ждать 5 секунд, а уж баннеры большинство однозначно не любит; поэтому при разработке страниц стоит все-таки стремиться к односекундной задержке до появления первого символа на экране.)
Однако баннер — только часть страницы, к тому же, для него, как правило, необходим отдельный поиск IP-адреса. Баннерообменные системы располагаются не в том же месте, где и сам сайт. Кроме того, нужно время на загрузку иллюстраций. Одним словом, время, затраченное на поиск IP-адресов, — это только часть времени загрузки, которое должно быть существенно меньше, чем приемлемое время загрузки страницы. На сколько меньше — определяется техническими ограничениями и реализацией алгоритма поиска в системе DNS.
Попытка — не пытка...
Алгоритм поиска IP-адреса по имени — многоступенчатый процесс, состоящий из серий попыток, которые выполняет «решатель» (resolver) и локальный кэширующий сервер (рис. 1). У каждого из них примерно одинаковый механизм опроса серверов доменных имен за исключением того, что кэширующий сервер применяет ранжирование авторитативных серверов зон по RTT. Рассмотрим этот алгоритм более внимательно.
В настройках resolver обычно указывают один-два сервера доменных имен, к которым он обращается с рекурсивными запросами. Процесс опроса начинается с первого сервера в списке и идет последовательно. Может быть совершено до четырех попыток. В первой попытке resolver ждет отклика от сервера 5 секунд, после чего переходит к следующему серверу. Если ответ не получен, то период ожидания увеличивается вдвое, и опрос серверов возобновляется с первого сервера в списке. Если resolver использует только один сервер, то тогда максимальное время ожидания отклика равно 75 секунд (5+10+20+40). Если серверов несколько, то возможны два варианта. В первом приведенный алгоритм справедлив для каждого сервера [13], а во втором время ожидания при каждой попытке на каждом сервере получается как результат деления установленного для данной попытки времени ожидания на число серверов. Например, для первой попытки и случая двух серверов оно будет равно 5/2 [14].
Следует пояснить, почему время суммируется. При рекурсивном запросе resolver перепоручает нахождение адреса локальному кэширующему серверу. Даже когда resolver начинает опрос второго сервера, первый сервер все равно пытается выполнить запрос (получить ответ и кэшировать его), поэтому при повторном обращении к нему он может иметь уже в своем распоряжении нужный ответ.
Перейдем ко второму звену поиска адреса — локальному кэширующему серверу. Он точно также опрашивает серверы, только их список он получает не из файла на диске, а из ответов других серверов. В нашем случае, когда мы не углубляемся в иерархию доменных имен дальше доменов второго уровня, список авторитативных серверов зоны домена второго уровня он получает от авторитативного сервера зоны RU. Список авторитативных серверов зоны RU он, в свою очередь, получает от корневого сервера, а список корневых серверов из своего файла настройки. Время кэширования списка авторитативных серверов зоны RU — одни сутки, поэтому основной вклад во время поиска будет вносить время доступа к авторитативным серверам искомой зоны домена второго уровня.
На самом деле разные серверы применяют разные алгоритмы выбора первого сервера для опроса [15] — BIND ранжирует серверы по RTT, а Windows выбирает просто случайным образом из полученного списка.
Что же дает анализ работы resolver в плане понимания компонентов времени отклика при поиске адреса? Во-первых, первым в настройках resolver должен быть указан сервер, который быстрее всего откликается на запросы клиента, поскольку локальный кэширующий сервер должен быть расположен как можно ближе к пользователю. Во-вторых, все серверы зоны должны быть одинаково хорошо расположены относительно пользователя (точнее, его кэширующего сервера), так как не факт, что клиент Windows, например, запросит тот сервер, который лучше всего расположен относительно него. В-третьих, с точки зрения «человеческого фактора» время задержки в 5 секунд достаточно велико для того, чтобы браузер пользователя многократно обращался к серверам.
Сухой остаток
Следует признать «приемлемым» время загрузки от 1 до 5 секунд, а в качестве цели, которую желательно достичь при разработке страниц сайтов, — 1 секунда до появления первого символа на экране пользователя. В качестве цели при размещении DNS-серверов следует признать такое время поиска в системе DNS, которое не превышало бы 0,15 с. Согласно измерениям времени отклика серверов доменных имен второго уровня в зоне RU, более половины серверов удовлетворяют этим условиям.
Для надежного обеспечения поиска своих ресурсов в сети следует не ограничиваться двумя авторитативными серверами, а увеличить их число до трех, чтобы не оказаться в ситуации приостановки делегирования.
«Хорошо» размещать нужно не только первичный (master) сервер зоны, но и все авторитативные серверы — неисправность любого из них грозит приостановкой делегирования, а кроме того, совершенно не обязательно, что resolver-сервер пользователя выберет при поиске первичный сервер.
У ИТ-общественности еще нет четкого понимания того, чем конкретно (убытки, потерянные пользователи, четко измеренные недопустимые задержки и т.п.) может грозить неправильное размещение DNS-сервера. Для Рунета никто не рассчитывал времена отклика на запрос ресурсов, не изучал составляющие времени отклика, и влияние всего этого на бизнес. Между тем, к примеру, при изменении маршрутизации в конце прошлого года тремя ведущими российскими провайдерами и увеличении RTT некоторые бизнесмены от Internet потеряли пользователей и, соответственно, понесли убытки, но их измерений и корреляций никто не делал. На Западе работы, посвященные измерению RTT тем же методом, что и рассмотренные в данной статье, были проведены в конце прошлого года [18]. Предполагается, что это поможет судить о влиянии RTT на эффективность работы Сети, однако пока эти работы еще не завершены. В общем случае, это достаточно серьезная проблема, затрагивающая оценку всего объема трафика, предоставляемого отечественными провайдерами.
Литература
Uniform Resource Identifiers (URI): Generic Syntax. RFC-2396, 1998 (http://www.ietf.org/rfc/rfc2396.txt?number=2396) Role of the Domain Name System (DNS). RFC-3467.2003 (http://www.ietf.org/rfc/rfc3467.txt?number=3467) P. Mockapetris. Domain Names - Concepts and Facilities. RFC-1034, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034) P. Mockapetris. Domain Names - Implementation and Specification. RFC-1035. 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035) Marina Fomenkov, kc claffy, Bradley Huffaker, David Moore. Macroscopic Internet Topology and Performance Measurements From the DNS Root Name Servers. 2001 LISA XV. December 2-7, 2001, San Diego, CA. Галицкий Е.Б. Опросы "Интернет в России". Выпуск 3. Весна 2003. ФОН. (http://www.fom.ru/reports/frames/o0316061.html) Аудитория Рунета по методике SpyLOG-монитор. 2003. Апрель. (http://gs.spylog.ru/interesting.phtml?id=53&PHPSESSID=817c3cea3231167985d03a45df37d2dc) Selection and Operation of Secondary DNS Servers. RFC-2182. 1997. (http://www.ietf.org/rfc/rfc2182.txt?number=2182) Регламент регистрации доменов в домене RU. 19.08.2002. (http://www.nic.ru/dns/contract/sup1_1_ru.html) Bob Bailey. Acceptable Computer Response Times. UI Design Update Newsletter - April, 2001. (http://www.humanfactors.com/downloads/apr012.htm) Bob Bailey. Improving User Performance. UI Design Update Newsletter - June, 2000. (http://www.humanfactors.com/downloads/june00.asp) Тимофей Бокарев. Энциклопедия Интернет-рекламы. (http://book.promo.ru/book/) Unix Manual Page for resolv.conf. (http://www.scit.wlv.ac.uk/cgi-bin/mansec?4+resolv.conf) The dig Manual Page. (http://www.stopspam.org/usenet/mmf/man/dig.html) Ryuji Somegawa, Kenjiro Cho, Yuji Sekiya, Suguru Yamaguchi. The Effects of Server Placement and Server Selection for Internet Services. IEICE Trans. Commun. Vol. E86-B, No. 2, February 2003. Yuji Sekiya, Kenjiro Cho, Ryuji Somagawa, Tatsuya Jinmei, Jun Murai. Root and ccTLD DNS server observation from worldwide locations. PAM2003. La Jolla, CA, April 6-8 2003. (http://moat.nlanr.net/PAM2003/PAM2003papers/3794.pdf) Статистика регистрации и делегирования доменов в зоне RU на 2003-06-16 (http://stat.nic.ru/2003/06/16/stats-20030616.shtml) Krishna P. Gummadi, Stefan Saroiu, Steven D. Gribble. King: Estimating Latency between Arbitrary Internet End Hosts. IMW 2002. November 6-8, 2002. (http://www.icir.org/vern/imw-2002/imw2002-papers/198.pdf)
Павел Храмцов (paul@kiae.su) — сотрудник РНЦ «Курчатовский Институт» (Москва)
DNS-услуги Internet-провайдера
Как правило, провайдер предоставляет клиенту целый комплекс услуг. В число оказываемых DNS-услуг входят:
делегирование зоны ...in-addr.arpa клиентам, имеющим пул адресов, кратный 256. регистрация доменного имени клиента у держателя той зоны, в которой клиент хочет зарегистрироваться; поддержание вторичного сервера прямой и обратной DNS-зон клиента; поддержание первичного сервера этих зон, если клиент по какой-либо причине не поддерживает их сам (особенно это относится к случаю виртуальных зон и к случаю выделения малого пула адресов);
Если провайдер будет отказываться - сошлитесь на меня. :-)
Domain Name Service - Служба Доменных Имен
Материалы книги П.Б. Храмцова,
Павел Храмцов,
Nicolai Langfeldt , перевод Alex Ott , v2.0.8, 25 Августа 1998, L i n u x P a r k, при поддержке
Перевод Плотникова А.С., Библиотека М. Мошкова
Дмитрий Карпов,
Дмитрий Карпов,
(Solaris)
(Solaris)
Виктор и Наталья Олифер, , из книги "Введение в IP-сети"
С.Клименко, В.Уразметов, из книги "Интернет - среда обитания"
Крутиков М. П., Слок Е. А., из статьи "СЕТЕВЫЕ СЛУЖБЫ INTERNET"
Составил А.Аликберов,
Domain Name ServiceСлужба Доменных Имен
Служба Доменных Имен предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.
Служба Доменных Имен была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.
Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "ясам".
Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.
Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко, а из шести и более мне неизвестны.
Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:
Клиент спрашивает своего сервера.
Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
Сервер спрашивает корневой сервер. Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна". Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна". Тот в свою очередь отсылает запрос серверу зоны "организация.город.страна", который сообщит нужную информацию.
Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.
Однако эту стройную картину искажают системы кэширования и вторичных серверов. Дело в том, что получив ответ на свой вопрос, DNS-сервер получает также некоторое число, которое говорит ему о том, по истечении какого времени эта информация должна считаться устаревшей. Таким образом, все серверы, участвовавшие в поиске ответа на вопрос, заданный клиентом, могут (и скорее всего будут) помнить как ответ на заданный вопрос, так и путь, по которому шел поиск. При следующих запросах, имеющих общую правую часть с недавно сделанными запросами, поиск будет упрощен (ускорен).
Кроме того, большинство зон имеет вторичные серверы, которые содержат копии данных с первичных серверов. Сервер вышележащей зоны может направить запрос как первичному серверу, так и любому из вторичных, основываясь на своих соображениях о том, какой из них ближе.
Хочу обратить особое внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран. Имена серверов выглядят так:
ftp.freebsd.org - первичный сервер в США ftp.страна.freebsd.org - основной сервер в стране
ftpчисло.страна.freebsd.org - дополнительный сервер в стране
Так например на 11 февраля 1998 года
ftp.ru.freebsd.org соответствует ftp.ru ftp2.ru.freebsd.org соответствует ftp.gamma.ru ftp3.ru.freebsd.org соответствует ftp.chg.ru
Таким образом, машины, находящиеся в России оказались произвольно (по воле DNS-мастера из университета Bercley) включенными в домен freebsd.org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.
Однако, некоторым сервисам этого недостаточно - так E-mail требует, чтобы машина, принимающая письмо, признала своим адрес, указанный в качестве пункта назначения. Протокол HTTP 1.1 (в 1.0 этого не было) требует, чтобы в HTTP-запросе указывался не путь к файлу, отсчитанный от корня сервера (хотя такие запросы тоже признаются), но и имя сервера; при этом сам сервер знает, какие имена - его, а остальные обрезает и обслуживает в соответствии с HTTP 1.0.
Делегирование зоны ...in-addr.arpa дается только от провайдера вместе с IP-адресами. Собственно, это связано с предназначением ReverceDNS - сообщать доменное имя по IP-адресу. Наверняка мастер зоны freebsd.org
держит Reverce-зону для IP-номеров, выделенных университету Bercley; но все эти серверы (кроме сервера, расположенного в университете) не входят в эту Reverce-зону, а значит, ему неподконтрольны.
Одна из проблем состит в том, что Reverce-зону можно выделить только на сеть класса A, B или C (на 16777216, 65536 или 256 адресов) и никак иначе. Можно получить правА на несколько зон одного или разных классов, но что делать тем, кому выделили меньше 256 адресов? А ведь в условиях исчерпания адресного пространства не редкость выделения пула уже на 16 адресов!
Домены верхнего уровня
Существующие общие домены
com - commercial (коммерческие) edu - educational (образовательные) gov - goverment (правительственные) mil - military (военные) net - network (организации, обеспечивающие работу сети) org - organization (некоммерческие организации)
Предполагаемые домены (в стадии утверждения)
FIRM - businesses, firms (коммерческие организации) SHOP - businesses offering goods to purchase (торговля, магазины) WEB - activities related to the WWW (веб-технологии) ARTS - cultural/entertainment activities (культура и искусство) REC - recreation/entertainment activities (развлечения) INFO - information services (информационные узлы) NOM - individual/personal nomenclature (индивидуальные и персональные узлы)
Список географических доменов первого уровня
| ДоменСтрана | ||||||
| AF | Afghanistan | Афганистан | LS | Lesotho | Лесото | |
| AL | Albania | Албания | LR | Liberia | Либерия | |
| DZ | Algeria | Алжир | LY | Libya | Ливия | |
| AS | American Samoa | LI | Liechtenstein | Лихтенштейн | ||
| AD | Andorra | Андорра | LT | Lithuania | Литва | |
| AO | Angola | Ангола | LU | Luxembourg | Люксембург | |
| AI | Anguilla | MO | Macao | Макао | ||
| AQ | Antarctica | Антарктика | MK | Macedonia, F.Y.R.O. | Македония | |
| AG | Antigua and Barbuda | MG | Madagascar | Мадагаскар | ||
| AR | Argentina | Аргентина | MW | Malawi | ||
| AM | Armenia | Армения | MY | Malaysia | Малайзия | |
| AW | Aruba | MV | Maldives | |||
| AU | Australia | Австралия | ML | Mali | Мали | |
| AT | Austria | Австрия | MT | Malta | Мальта | |
| AZ | Azerbaijan | Азербайджан | MH | Marshall Islands | Маршалловы Острова | |
| BS | The Bahamas | Багамы | MQ | Martinique | Мартиника | |
| BH | Bahrain | MR | Mauritania | Мавритания | ||
| BD | Bangladesh | Бангладеш | MU | Mauritius | ||
| BB | Barbados | Барбадос | YT | Mayotte | ||
| BY | Belarus | Беларусь | MX | Mexico | Мексика | |
| BE | Belgium | Бельгия | FM | Micronesia | Микронезия | |
| BZ | Belize | MD | Moldova | Молдавия | ||
| BJ | Benin | MC | Monaco | Монако | ||
| BM | Bermuda | Бермуды | MN | Mongolia | Монголия | |
| BT | Bhutan | MS | Montserrat | Монсеррат | ||
| BO | Bolivia | Боливия | MA | Morocco | Марокко | |
| BA | Bosnia and Herzegovina | Босния и Герцеговина | MZ | Mozambique | Мозамбик | |
| BW | Botswana | Ботсвана | MM | Myanmar | ||
| BV | Bouvet Island | NA | Namibia | Намбия | ||
| BR | Brazil | Бразилия | NR | Nauru | ||
| IO | British Indian Ocean Territory | NP | Nepal | Непал | ||
| BN | Brunei Darussalam | NL | Netherlands | Нидерланды | ||
| BG | Bulgaria | Болгария | AN | Netherlands Antilles | ||
| BF | Burkina Faso | NC | New Caledonia | Новая Каледония | ||
| BI | Burundi | NZ | New Zealand | Новая Зеландия | ||
| KH | Cambodia | Камбоджа | NI | Nicaragua | Никарагуа | |
| CM | Cameroon | Камерун | NE | Niger | Нигер | |
| CA | Canada | Канада | NG | Nigeria | Нигерия | |
| CV | Cape Verde | NU | Niue | |||
| KY | Cayman Islands | NF | Norfolk Island | Норфолкские Острова | ||
| CF | Central African Republic | Центральная Африканская Республика | MP | Northern Mariana Islands | ||
| TD | Chad | Чад | NO | Norway | Норвегия | |
| CL | Chile | Чили | OM | Oman | Оман | |
| CN | China | Китай | PK | Pakistan | Пакистан | |
| CX | Christmas Island | PW | Palau | |||
| CC | Cocos (Keeling) Islands | PA | Panama | Панама | ||
| CO | Colombia | Колумбия | PG | Papua New Guinea | Новая Гвинея | |
| KM | Comoros | PY | Paraguay | Парагвай | ||
| CG | Congo | Конго | PE | Peru | Перу | |
| CK | Cook Islands | PH | Philippines | Филиппины | ||
| CR | Costa Rica | КостаРика | PN | Pitcairn | ||
| CI | Cфte d'Ivoire | PL | Poland | Польша | ||
| HR | Croatia | PT | Portugal | Португалия | ||
| CU | Cuba | Куба | PR | Puerto Rico | ПуэртоРико | |
| CY | Cyprus | Кипр | QA | Qatar | ||
| CZ | Czech Republic | Чехия | RE | Reunion | ||
| DK | Denmark | RO | Romania | Румыния | ||
| DJ | Djibouti | RU | Russia | Россия | ||
| DM | Dominica | RW | Rwanda | |||
| DO | Dominican Republic | Доминиканская Республика | KN | Saint Kitts and Nevis | ||
| TP | East Timor | LC | Saint Lucia | СантаЛючия | ||
| EC | Ecuador | Эквадор | VC | Saint Vincent and the Grenadines | ||
| EG | Egypt | Египт | WS | Samoa | Самоа | |
| SV | El Salvador | Сальвадор | SM | San Marino | СанМарино | |
| GQ | Equatorial Guinea | Экваториальная Гвинея | ST | Sao Tome and Principe | ||
| ER | Eritrea | SA | Saudi Arabia | Саудовская Аравия | ||
| EE | Estonia | Эстония | SN | Senegal | Сенегал | |
| ET | Ethiopia | Эфиопия | SC | Seychelles | Сейшелы | |
| FK | Falkland Islands (Malvinas) | SL | Sierra Leone | Сьерра Леоне | ||
| FO | Faroe Islands | SG | Singapore | Сингапур | ||
| FJ | Fiji | Фуджи | SK | Slovakia | Словакия | |
| FI | Finland | Финляндия | SI | Slovenia | Словения | |
| FR | France | Франция | SB | Solomon Islands | Соломоновы Острова | |
| FX | France Mйtropolitaine | SO | Somalia | Сомали | ||
| GF | French Guyana | Французская Гвиана | ZA | South Africa | Южная Африка | |
| PF | French Polynesia | Полинезия | GS | South Georgia and the South Sandwich Islands | ||
| TF | French Southern Territories | ES | Spain | Испания | ||
| GA | Gabon | Габон | LK | Sri Lanka | Шри Ланка | |
| GM | Gambia | Гамбия | SH | St. Helena | ||
| GE | Georgia | Грузия | NO | St. Pierre and Miquelon | ||
| DE | Germany | Германия | SD | Sudan | Судан | |
| GH | Ghana | Гана | SR | Suriname | Суринам | |
| GI | Gibraltar | Гибралтар | SJ | Svalbard and Jan Mayen Islands | ||
| GR | Greece | Греция | SZ | Swaziland | ||
| GL | Greenland | SE | Sweden | Швеция | ||
| GD | Grenada | Гренада | CH | Switzerland | Швейцария | |
| GP | Guadeloupe | Гваделупа | SY | Syria | Сирия | |
| GU | Guam | TW | Taiwan | Тайвань | ||
| GT | Guatemala | Гватемала | TJ | Tajikistan | Таджикистан | |
| GG | Guernsey | TZ | Tanzania | Танзания | ||
| GN | Guinea | Гвинея | TH | Thailand | Таиланд | |
| GW | Guinea-Bissau | Гвинея-Биссау | TG | Togo | Того | |
| GY | Guyana | Гвиана | TK | Tokelau | ||
| HT | Haiti | TO | Tonga | Тонга | ||
| HM | Heard and McDonald Islands | TT | Trinidad and Tobago | Тринидад | ||
| HN | Honduras | Гондурас | TN | Tunisia | Тунис | |
| HK | Hong Kong | Гонконг | TR | Turkey | Турция | |
| HU | Hungary | Венгрия | TM | Turkmenistan | Туркменистан | |
| IS | Iceland | Исландия | TC | Turk and Caicos Islands | ||
| IN | India | Индия | TV | Tuvalu | ||
| ID | Indonesia | Индонезия | UG | Uganda | Уганда | |
| IR | Iran | Иран | UA | Ukraine | Украина | |
| IQ | Iraq | Ирак | AE | United Arab Emirates | Объединенные Арабские Эмираты | |
| IE | Ireland | Ирландия | UK | United Kingdom | Великобритания | |
| IM | Isle of Man | US | United States | США | ||
| IL | Israel | Израиль | UM | U.S. Minor Outlying Islands | ||
| IT | Italy | Италия | UY | Uruguay | Уругвай | |
| JM | Jamaica | Ямайка | UZ | Uzbekistan | Узбекистан | |
| JP | Japan | Япония | VU | Vanuatu | ||
| JE | Jersey | Джерси | VA | Vatican City State | Ватикан | |
| JO | Jordan | Джордан | VE | Venezeula | Венесуэлла | |
| KZ | Kazakhstan | Казахстан | VN | Vietnam | Вьетнам | |
| KE | Kenya | Кения | VG | Virgin Islands (British) | ||
| KI | Kiribati | VI | U.S. Virgin Islands | |||
| KP | Korea, North | Северная Корея | WF | Wallis and Futuna Islands | ||
| KR | Korea, South | Южная Корея | EH | Western Sahara | ||
| KW | Kuwait | Кувейт | YE | Yemen | Йемен | |
| KG | Kyrgyzstan | Кыргызстан | YU | Yugoslavia | Югославия | |
| LA | Laos | Лаос | ZR | Zaire | Заир | |
| LV | Latvia | Латвия | ZM | Zambia | Замбия | |
| LB | Lebanon | ZW | Zimbabwe | Зимбабве |
Ссылки
Составил
Файл 1_168_192.rev
@ IN SOA troll.фирма.домен. ответственный_за_зону. ( 19970315 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ; Minimum )
Тут даже думать не надо.
1 IN PTR troll.фирма.домен. 2 IN PTR ogre.фирма.домен. 11 IN PTR dwarf.группа.фирма.домен. 12 IN PTR elf.группа.фирма.домен. ; и так далее
Этот файл содержит преобразования IP-адресов в доменные имена. Многие программы вообще отказываются работать с машинами, чей IP-адрес не прописан в обратной (reverce) зоне, видимо, считая, что этот адрес кем-то присвоен самовольно, без санкции ответственного администратора.
Здесь же мы должны прописать все остальные машины, имеющие IP-номера 192.168.1.* - дело в том, что зоны в in-addr.arpa
выделяются сразу на 256 адресов и не делегируются на меньшее число.
Хочу также обратить внимание на то, что в обратной зоне нет машины goblin: она находится в совсем другой обратной зоне.
Файл филиал_фирма_домен.hosts
Этот файл создается автоматически; главное - чтобы он был правильно построен (прописаны все NS и MX).
Файл фирма_домен.hosts
Файл фирма_домен.hosts достаточно велик, поэтому я буду перемежать текст файла обьяснениями.
@ IN SOA troll.фирма.домен. ответственный_за_зону. ( 19970315 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ; Minimum )
Да в общем-то нет никаких причин делать эту зону отличной от зоны, содержащейся в , разве что Serial может (и скорее всего будет) различаться.
IN NS troll IN NS ogre IN NS вторичный_сервер_провайдера.
Раз у нас есть вторичный сервер, да к тому же провайдер обещал держать у себя на сервере копию нашего сервера, надо авторизовать их тоже.
IN MX 10 troll IN MX 20 почтовый_шлюз_провайдера.
Здесь описаны почтовые шлюзы в порядке возрастания "удаленности" от пункта назначения. Почтовые серверы, имеющие почту для наших машин, пытаются послать ее непосредственно по адресу назначения; если это не удается, они пытаются послать ее самому близкому к пункту назначения шлюзу, при неудаче - следующему и так далее до исчерпания списка. Это касается только адреса фирма.домен, но не относится к машинам зоны (см.ниже).
localhost IN A 127.0.0.1
Каждая машина, обратившаяся по адресу localhost или localhost.зона, должна получить номер 127.0.0.1.
* IN MX 10 troll IN MX 20 почтовый_шлюз_провайдера.
Для всех машин данной зоны установить почтовые шлюзы (те же, что и для самОй зоны).
troll IN A 192.168.1.1 IN HINFO "486DX2-66" "FreeBSD" ns IN CNAME troll mail IN CNAME troll
IN A 192.168.1.1
Определяет, что имени troll соответствует IP-номер 192.168.1.1. IN HINFO "486DX2-66" "FreeBSD"
Содержит некоторыю информацию о машине, обычно - тип процессора и операционной системы. ns IN CNAME troll и mail IN CNAME troll
Делают имена ns и mail псевдонимами машины troll. Следует помнить, что этого не всегда достаточно: некоторые протоколы, включая HTTP 1.1 и E-mail работают непосредственно с именем хоста, так что сам хост тоже должен понимать, что это имя - его.
ogre IN A 192.168.1.2 IN HINFO "Pentium" "Linux" nss IN CNAME troll www IN CNAME ns.misa.ac.ru. ftp IN CNAME ns.misa.ac.ru.
goblin IN A 172.16.21.114
В общем- то все то же самое, что и для troll.
группа IN MX 5 dwarf.группа IN MX 10 troll IN MX 20 почтовый_шлюз_провайдера. *.группа IN MX 5 dwarf.группа IN MX 10 troll IN MX 20 почтовый_шлюз_провайдера.
На всякий случай отдельно зафиксируем почтовые шлюзы как для самой группы, так и для всех ее машин.
localhost.группа IN A 127.0.0.1 elf.группа IN A 192.168.1.11 dwarf.группа IN A 192.168.1.12
Обычные записи для машин группы. Можно сделать им HINFO или добавить псевдонимы, но и так сойдет.
отдел IN NS 192.168.1.21. ; и, если есть, вторичные Name-серверы
Так как отдел имеет свой Name-сервер, нужно только авторизовать его, причем по номеру; а дальше он сам должен отвечать за записи своей зоны.
И напоследок - красивый фокус:
altavista IN CNAME altavista.digital.com yahoo IN CNAME www.yahoo.com
Это позволяет моим юзерам обращаться к самым известным поисковым машинам, не набирая www. в начале и .com в конце! Однако, когда я пытался обращаться к этим машинам через Proxy-сервер провайдера, тот обратился к своей зоне DNS и сказал: "Не знаю имени yahoo.провайдер! Впрочем, полное имя www.yahoo.com продолжало нормально функционировать. Есть еще одна особенность такой конфигурации: машина yahoo.фирма.домен
находится в нашей зоне, поэтому некоторые программы, кэширующие обращения к WWW, могут решить, что ее кэшировать не надо.
Файл localhost.rev
@ IN SOA troll.фирма.домен. ответственный_за_зону. ( 19970315 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ; Minimum
IN NS troll.фирма.домен. 1 IN PTR localhost.домен.
Пояснения:
@
текущий исходный домен, от которого будут отсчитываться все имена, которые не заканчиваются на точку. в данном случае - 0.0.127.in-addr.arpa.
IN
Запись относится к InterNet. Должно присутствовать во всех записях, но часто это игнорируют. SOA
Start Of Authorisation - Начало Полномочий. первичный_сервер_зоны.
Имя первичного сервера зоны. Так как мы создаем этот файл на первичном серере, здесь должно быть доменное имя самОй машины; точка в конце обязательна. ответственный_за_зону.
Почтовый адрес лица, отвественного за зону; "@" в адресе заменяется на ".". В скобки заключаются параметры, растянутые на несколько строк:
19970315 ; Serial Серийный номер версии; должен увеличиваться при каждом изменении в зоне - по нему вторичный сервер обнаруживает, что надо обновить информацию. Обычно пишется в виде <год><месяц><число><номер>. 3600 ; Refresh Временной интервал в секундах, через который вторичный сервер будет проверять необходимость обновления информации. 300 ; Retry Временной интервал в секундах, через который вторичный сервер будет повторять обращения при неудаче. 3600000 ; Expire Временной интервал в секундах, через который вторичный сервер будет считать имеющуюся у него информацию устаревшей. 3600 ) ; Minimum Значение времени жизни информации на кэширующих серверах.
IN NS первичный_сервер_зоны.
Запись NS авторизует сервер как ответственный за зону. Естественно, надо авторизовать самогО себя.
1 IN PTR localhost.домен.
Номер 127.0.0.1 всегда должен быть localhost. .0.0.127. автоматически приписывается к 1, ибо она не кончается на точку.
Файл named.boot
directory /etc/namedb
Это - указание на то, в какой директории находятся все упоминаемые дальше файлы.
primary 0.0.127.in-addr.arpa
Каждый Name-сервер должен обслуживать зону 0.0.127.in-addr.arpa, ибо каждая машина должна знать свой внутренний номер как localhost.
primary фирма.домен
Это - домен, выделенный нашей организации.
primary 1.168.192.in-addr.arpa
Это - обратное преобразование IP-адресов в имена.
secondary филиал.фирма.домен 192.168.1.193
Для ускорения обращений к Name-серверу филиала на нашем сервере должна быть копия содержимого его зоны.
Формат файлов
|<- | Текст файла начинается с этой позиции. |<-
Формат файла:
имя аргументы
В качестве разделителя используются пробелы и табуляции.
Пустые строки игнорируются.
Точкас запятой ";" - признак комментария; все от нее до конца строки игнорируется.
Если строка начинается с пробела или с табуляции, она относится к тому же имени, что и предыдущая строка.
Инструменты
Для тестирования правильности построения зоны используется программа nslookup. Она сообщает IP-адрес по доменному имени, а при запуске без параметров она переходит в командный режим, где проявляет все свои незаурядные качества - читай `man nslookup`.
Политика и стратегия назначения имен
Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегестрированы следующие "организационные" зоны:
com - commercial (коммерческие) edu - educational (образовательные) gov - goverment (правительственные) mil - military (военные) net - network (организации, обеспечивающие работу сети) org - organization (некоммерческие организации)
В данный момент, чтобы разгрузить домен com, собираются создать несколько новых доменов, но у меня нет достоверной информации по ним. В организационных зонах обычно размещаются непосредственно домены организаций.
Каждая страна (государство) имеет свой географический домен из двух букв:
ae - United Arab Emirates (Объединенные Арабские Эмираты) au - Australia (Австралия) be - Belgium (Бельгия) br - Brazil (Бразилия) by - Belarus (Белоруссия) ca - Canada (Канада) ch - Switzerland (Швейцария) cz - Czech Republic (Чехия) de - Germany (Германия) dk - Denmark do - Dominican Republic (Доминиканская республика) ee - Estonia (Эстония) eo - ??? es - Spain (Испания) fi - Finland (Финляндия) fr - France (Франция) hu - Hungary (Венгрия) il - Israel (Израиль) in - India (Индия) iz - ??? jp - Japan (Япония) kg - Kyrgyzstan (Кыргызстан) kr - South Korea (Южная Корея) kz - Kazakhstan (Казахстан) lt - Lithuania (Литва) lv - Latvia (Латвия) mx - Mexico (Мексика) nl - Netherlands (Нидерланды) no - Norway (Норвегия) nz - New Zealand (Новая Зеландия) pl - Poland (Польша) ro - Romania (Румыния) ru - Russia (Россия) si - Slovenia (Словения) sk - Slovak Republic (Словакия) su - Soviet Union (Советский Союз - поддерживается, но не распределяется) ua - Ukraine (Украина) uk - United Kingdom (Соединенное Королевство ВеликоБритания / Англия) yu - Yugoslavia (Югославия) za - South Africa (Южная Африка)
Я перечислил отнюдь не все страны - кто хочет, может прислать мне другие названия.
В зонах государств опять же имеются "организационные" и "географические" зоны. "Организационные" в большинстве своем повторяют структуру "организационных" зон верхнего уровня, разве что вместо "com" используется "co". "Географические" выделяются городам, областям и т.п. территориальным образованиям. Непосредственно в тех и других размещаются домены организаций или домены персональных пользователей.
После выбора зоны, в которую будет включен наш домен надо выбрать собственное имя домена. Обычно это имя компании, торговая марка или что-нибудь столь же характерное. Для неанглоязычных стран используется транскрипция имен. Часто возникают конфликты, связанные с тем, что одно и то же имя используется несколькими фирмами (законодательство допускает это для фирм, работающих в разных отраслях); многие люди заранее резервируют имена, могущие стать популярными для последующей продажи их владельцу торговой марки; но это уже касается юридической стороны функционирования Internet и не входит в мою компетенцию.
С левого конца доменного имени находятся имена машин. Имена бывают "собственные" и "функциональные". Имена "собственные" каждый придумавает в меру фантазии: машинам присваиваются имена членов семьи, животных, растений, музыкантов и артистов, литературных персонажей - кто во что горазд.
Имена "функциональные" вытекают из функций, выполняемых машиной:
www - HTTP (WWW) сервер ftp - FTP сервер ns, nss, dns - DNS (Name) сервер mail - Mail сервер relay - Mail Exchanger *proxy - соответствующий Proxy сервер
Я считаю нежелательным присваивать какой-либо машине функциональное имя - в любой момент может потребоваться перенести соответствующую функцию на другую машину. Для этого лучше всего использовать псевдонимы, которые перенаправляют запросы к данному имени на записи, относящиеся к другому имени. Но вот ссылаться на псевдонимы при обьявлении Mail Exchanger'ов и вообще использовать их в правой части записей считается нежелательным, а зачастую является недопустимым.
Пример настройки Name-сервера
Спланируем нашу зону так:
наша фирма получила зону "фирма.домен"; в ней будет три машины со следующими функциями:
troll первичный Name-сервер; почтовая машина; ogre вторичный Name-сервер; FTP- и WWW-сервер; goblin просто машина без каких-либо функций, да еще расположенная совершенно в другом месте.
Имеется группа "группа.фирма.домен" с двумя машинами:
dwarf почтовый шлюз группы elf просто машина
Имеется отдел "отдел.фирма.домен" со своим Name-сервером. Имеется удаленный филиал "филиал.фирма.домен" со своим Name-сервером, который надо дублировать.
Ссылки:
WINS - Window Internet Name Service
Отслеживает соответствие имен Windows Network и IP-номеров машин. Аналог DNS, но с динамическим отлеживанием и без какого-либо масштабирования. NDS - Novell Directory Service
Служит для определения местонахождения сервера, на котором находится данная сетевая директория (аналог ресурса в Windows Network). Active Directory
Micro$oft'овский аналог NDS. WindowsNT Domain
Система централизованного хранения базы данных о правах и паролях пользователей. Никакого отношения к службе имен не имеет, здесь приведена для устранения возможной путаницы, вызваной созвучием названий.
Старт
При старте машины запускается DNS-сервер:
named -b /etc/namedb/
В качестве аргумента ему передается имя файла с описанием рабочей конфигурации.
