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

   
 Купля-продажа и обсуждение доменных имён
        

  
Вернуться   Форум о доменах > Обсуждение доменных имён > Для новичков домен-индустрии
Регистрация Реноме Правила форума Справка Пользователи Социальные группы Все разделы прочитаны
Для новичков домен-индустрии
Если Вы не совсем понимаете о чём идёт речь на данных форумах, то добро пожаловать в раздел для новичков, где Вам наглядно объяснят что к чему и ответят на любой Ваш вопрос

Ответ
 
Опции темы
Сегодня
от 149р за .RU
Аренда сервера
2x Intel Hexa-Core Xeon E5-2420
Всего 79 евро!

с видеокартой GeForce GTX 1080 Ti
всего 99 евро!

от 149р за .РФ Реклама на DomenForum.net
Старый 30.12.2004, 22:44   #1
Почетный форумчанин
 
Аватар для Alex
 
Регистрация: 27.12.2004
Адрес: Чикаго (USA)
Сообщений: 7,486
Доменные сделки: 37
Реноме: 4413
Одобрения
Отправить сообщение для Alex с помощью ICQ Отправить сообщение для Alex с помощью Skype™
Как правильно разместить DNS-сервер

Как правильно разместить DNS-сервер

Среди ИТ-специалистов все более популярным сегодня становится вопрос разработки систем распространения контента (content distribution system), на успех работы которых очень влияет размещение информационных серверов. Речь идет о таком размещении серверов, при котором время доступа было бы если не минимальным, то хотя бы приемлемым (отвечающим SLA). Фактически, требуется в единицу времени обслужить максимальное число пользователей при заданном времени обслуживания одного. Например, для Web-страниц таким ограничивающим фактором будет приемлемое время загрузки страницы браузером, которое складывается не только из времени передачи данных по сети и времени их интерпретации, но также и времени, затраченного на поиск IP-адреса сервера в том числе и из времени обращения к сервису Системы Доменных Имен (DNS).

Мой адрес не дом и не улица…

Система доменных имен Internet – ключевой сервис, на который в сети замыкаются адреса информационных ресурсов, а точнее их идентификаторы (Uniform Resource Identifier, URI, RFC-2396 [1]). Как отмечено в RFC-3467 [2], посвященном роли системы доменных имен, архитектура DNS оставалась неизменной с момента своего создания, в то время как ее функции существенно изменились -- коммерциализация Сети привела к существенному «уплощению» иерархии доменных имен. Владельцы сервисов предпочитают использовать домены 2-ого уровня в рамках национальных доменов или доменов общего назначения, например microsoft.com, а не закапываться вглубь иерархии имен. Кроме того, начиная с 90-х годов, систему DNS стали использовать в качестве инструмента балансировки нагрузки серверов информационных ресурсов, эксплуатируя для этого алгоритм Round Robin, который применяется серверами доменных имен при ответе на запросы клиентов. Ни первое, ни второе при проектировании системы доменных имен не предполагалось. Во всяком случае, в основополагающих документах RFC-1034 [3] и RFC-1035 [4] этого не указано.

Вспомним типовую схему поиска IP-адреса по доменному имени (рис.1)


Рис.1. Схема получения IP-адреса по известному доменному имени в системе DNS

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

На схеме (Рис. 1) указаны два типа запросов: рекурсивный и нерекурсивный. Первый – это запрос, при котором клиент перепоручает поиск IP-адреса серверу, второй – запрос при котором клиент сам производит опрос серверов. Локальный кэширующий сервер самостоятельно опрашивает все серверы доменных имен, поэтому он обменивается с ними нерекурсивными запросами.

В системе доменных имен существует жесткая иерархия имен. Начинается она с корня, который часто обозначают как «.», хотя это и не совсем правильно. Затем следуют домены верхнего уровня (Top Level Domains, TLD), например, com., org., net., ru. и т.п. Далее следуют домены второго уровня, например, nic.ru, vesti.ru и т.п. Каждый домен поддерживается авторитарным сервером домена и, как правило, не одним. При этом сервер, который поддерживает старшие имена, имеет возможность перепоручить управление младшими именами другому серверу. Такое перепоручение отражается в описании домена, управляемом сервером, и называется делегированием. Та часть дерева иерархи имен, которой управляет сервер, называется зоной. Если серверу поручено управлять корнем дерева имен, и он перепоручил все TLD другим серверам, то в его ведении остается только управление соответствиями между именами доменов и именами серверов, которым он эти домены перепоручил.

Кому поручено управления младшими именами, знает только тот сервер, который осуществляет делегирование, поэтому, когда мы ищем что-то в домене RU, мы сначала должны узнать, кто поддерживает домен RU, а потом, кто поддерживает ту часть домена RU, которая, собственно, нас и интересует. На первый вопрос отвечает корневой сервер, который обслуживает «корень» имен DNS – корневую зону. Таких серверов 13 -- 10 в США, 2 в Европе и один в Японии. До сих пор такое размещение было оправдано (согласно данным CIADA (Cooperative Association for Internet Data Analysis) [5] около 60% клиентов корневых серверов размещены в США). На второй вопрос ответят серверы, поддерживающие национальный домен RU. Их шесть: три размещены в России и три в Европе. Кстати, если верить статистике Фонда «Общественное мнение» [6], то 19% пользователей Рунета находятся в Москве, там же, где расположены и три российских сервера зоны RU. С точки зрения использования DNS, правильнее ориентироваться на данные SpyLog, которые получены на основе агрегирования статистики его счетчиков, размещенных на Web-сайтах -- на апрель 2003 года в Москве находилось 43% всех городских пользователей Рунета [7].

После получения ответа с сервера, поддерживающего национальный домен, мы можем обратиться к авторитативному (authorative) серверу домена, которому принадлежит интересующее нас имя. Авторитативным этот сервер называют по той причине, что именно ему делегировано право отвечать на запросы к именам из этого домена. По правилам делегирования доменов второго уровня в RU для каждого домена таких серверов должно быть не менее двух. Вообще говоря, их может быть и больше -- RFC-2182 [8] рекомендует иметь три. Нарушением регламента регистрации доменов, способным повлечь временную приостановку делегирования, является ситуация когда, суммарное время отсутствия связи с сервером превышает два часа за сутки [9]. Ели домен обеспечен тремя серверами, то вероятность отказа сразу на двух серверах меньше, чем на одном, что существенно понижает риск временной потери делегирования. На самом деле, локальный кэширующий сервер доменных имен обращается к корневым серверам и авторитативным серверам домена RU только тогда, когда не может найти необходимый ему адрес в своем кэше.

Время хранения соответствий в кэше сервера определяется временем TTL (Time To Live), которое устанавливает администратор соответствующего домена. Например, TTL имен авторитативных серверов домена RU равно 86400 секунд или 1 сутки, т.е. после первого обращения за адресом из домена RU локальный кэширующий сервер доменных имен обратиться к корневому серверу за получением списка авторитативных серверов домена RU только через сутки. Аналогичная схема работает и для всех остальных доменов. Если один пользователь обратился, например, к www.yandex.ru через локальный кэширующий сервер dialup провайдера, то этот сервер будет обслуживать всех остальных пользователей этого провайдера в течение суток, не обращаясь ни к корневым серверам доменных имен, ни к авторитативным серверам домена RU. Но, если в качестве примера выбрать www.rambler.ru, то такое кэширование (по данным на июнь 2003 года) будет осуществляться только 1 час. А для mail.ru это время будет равно двум часам. Таким образом, для конкретного пользователя системы DNS время отклика будет варьироваться от времени полного опроса всех серверов, обслуживающих искомый адрес, начиная от корневого сервера и кончая авторитативным сервером поддомена, до времени опроса только своего локального кэширующего сервера.

Вернемся к вопросу о времени отклика на запрос, а точнее к RTT (Round Trip Time), которое обычно и используют в качестве основы различных метрик в расчетах эффективности размещения сервисов [5].

Не думай о секундах с высока…

Итак, мы хотим добиться приемлемого для пользователя времени обработки запроса, однако, прежде разберемся чему может быть равно это время.

Как показывают исследования [10, 11], все зависит от того, какую задачу решает пользователь. При этом обычно исследуют либо время задержки, которое начинает вызывать раздражение, либо влияние времени задержки на эффективность работы в целом. Обычно время задержки (загрузки Web-страницы) свыше 1 с., вызывает дискомфорт, однако, если пользователь знает, что он получит, то раздражения не вызывают и задержки до 5 секунд. Но после 30 с. речь уже не может идти об интерактивной работе. В целом для работы с известным интерфейсом подходит следующая шкала: до 5 секунд – «хорошо»; до 10 секунд – «удовлетворительно»; более 10 секунд – «плохо». Однако, если показывать элементы страницы по мере их получения, то шкала для времени полной загрузки страницы изменится: до 39 с. – «хорошо»; до 56 с. – «удовлетворительно»; более 56 секунд – «плохо». Любопытно и другое -- непреодолимое желание «ускорить» процесс возникает в среднем после 8,6 секунд ожидания хоть какого-нибудь результата.

С приемлемостью времени загрузки до 5 секунд согласны и «художники» баннеров, рекомендуя стандартный размер баннера в 10-15 Кбайт [12] – именно столько удается передать при dialup-соединении со скоростью 28800 бит/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 начинает опрос второго сервера, первый сервер все равно пытается выполнить запрос (получить ответ и его закэшировать), поэтому при повторном обращении к нему он может уже иметь в своем распоряжении нужный ответ.

Теперь перейдем ко второму звену поиска адреса – локальному кэширующему серверу. Он точно также опрашивает сервера, только их список он получает не из файла на диске, а из ответов других серверов. В нашем случае, когда мы не углубляемся в иерархию доменных имен дальше доменов второго уровня, список авторитативных серверов зоны домена 2-ого уровня он получает от авторитативного сервера зоны RU. Список авторитативных серверов зоны RU он, в свою очередь, получает от корневого сервера, а список корневых серверов из своего файла настройки. Время кэширования списка авторитативных серверов зоны RU – одни сутки, поэтому основной вклад во время поиска будет вносить время доступа к авторитативным серверам искомой зоны домена второго уровня.

На самом деле различные серверы применяют различный алгоритм выбора первого сервера для опроса [15] -- BIND ранжирует серверы по RTT, а Windows выбирает просто случайным образом из полученного списка.

Что же дает анализ работы resolver в плане понимания компонентов времени отклика при поиске адреса? Во-первых, первым в настройках resolver должен быть указан сервер, который быстрее всего откликается на запросы клиента, т.е. локальный кэширующий сервер должен быть расположен как можно ближе к пользователю. Во-вторых, все серверы зоны должны быть одинаково хорошо расположены относительно пользователя, точнее его кэширующего сервера, т.к. не факт, что клиент Windows, например, запросит тот сервер, который лучше всего расположен относительно него. В-третьих, с точки зрения «человеческого фактора» время задержки в 5 секунд достаточно большое для того, чтобы браузер пользователя многократно обращался к серверам.

Что такое хорошо, и что такое плохо…

Какое время отклика DNS сервера принято считать «хорошим», а какое «плохим»? Посмотрим при этом на наиболее загруженные и критичные с точки зрения всей системы серверы – корневые и те, что обслуживают «национальные» домены.

За последние два года было проведена ряд исследований в этой области. Специалисты CIADA[5] изучали время отклика корневых серверов на запросы клиентов со всего земного шара. Время отклика признавалось большим, если превышало 90% точку распределения времени отклика. Типичным большим временем отклика в этом исследовании было время большее 0,5 с. Следует заметить, что для России из 437 точек только 14 имели большое время отклика (3% от общего числа российских участников), что сравнимо с данными по Бразилии. Важно также, что за полгода пока проводились эти исследования доля точек в России с большим откликом не изменилась (например, на Украине она увеличилась в два раза) и была отмечена общая тенденция к сокращению времени отклика.

Более точные измерения проведены работе [16]. Если в CIADA измерялось RTT от серверов к опрашивающим их хостам, то здесь использовалась программа, которая, будучи установленной в различных точках Сети и измеряла непосредственно отклик корневых серверов и серверов национальных доменов. Согласно данным [16] для США и Европы характерным временем отклика является время меньше 0,2 с. Здесь следует оговориться. В силу различных причин, основной объем DNS трафика приходится на корневой A-сервер, поэтому именно время отклика от этого сервера и является определяющим, а оно при прямом подключении (исследовался также и dialup) в редких случаях превышает 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.


Рис.2. Распределение времени отклика серверов доменов второго уровня в зоне RU

Cогласно статистике компании 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 (2 порядка величины) выглядят на этом фоне, мягко говоря, странно.

Следует учитывать тот факт, что серверы, поддерживающие домены второго уровня в зоне 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 предполагают «одинаковость» авторитативных серверов доменов.
Alex вне форума   Ответить с цитированием
Старый 13.01.2005, 18:42   #2
 
Регистрация: 12.01.2005
Сообщений: 44
Доменные сделки: 0
Реноме:
Одобрения
Спасибо (Отдано): 0
Спасибо (Получено): 0
Отправить сообщение для winter с помощью ICQ
расскажите плиз:как подключиться к инету через CDMA2000;как активировать виндоус если он ни вкакую этого делать нехочет;как завести себе страничку в spb.ru;где найти толкового дизайнера для её оформления;и еще множество вопросов от Ньюбов..=)))
P.S. просьба ответить..=))
winter вне форума   Ответить с цитированием
Старый 16.01.2005, 15:22   #3
 
Регистрация: 16.01.2005
Сообщений: 49
Доменные сделки: 0
Реноме:
Одобрения
Спасибо (Отдано): 0
Спасибо (Получено): 0
Отправить сообщение для Re:KpyT с помощью ICQ
а меня вот что интересует... у меня сейчас есть выделенный внешний IP как мне к нему привязать доменное имя или это делает тот провайдер у которого я его регистрирую и ли ещё проще с покупкой доменного имени второго уровня они мне присваивают новый анешний IP и доменное имя? я просто в это не вдавался... А то мне предстоит в скором покупка доменнного имени я вот и не знаю что делать
Re:KpyT вне форума   Ответить с цитированием
Старый 19.03.2005, 14:42   #4
 
Регистрация: 19.03.2005
Сообщений: 34
Доменные сделки: 0
Реноме:
Одобрения
Спасибо (Отдано): 0
Спасибо (Получено): 0
Отправить сообщение для endorfine с помощью ICQ
Сообщение от Re:KpyT
а меня вот что интересует... у меня сейчас есть выделенный внешний IP как мне к нему привязать доменное имя или это делает тот провайдер у которого я его регистрирую и ли ещё проще с покупкой доменного имени второго уровня они мне присваивают новый анешний IP и доменное имя? я просто в это не вдавался... А то мне предстоит в скором покупка доменнного имени я вот и не знаю что делать
Насколько я понял, ты покупаеш себе доменное имя и это доменное имя прописывается в DNS с привязкой к IP твоего хоста.

Прописывает тот, у кого ты его покупал. Когда покупаешь просто пишешь ip адрес своего хоста и они их связывают одной простой строчкой %)

Это сделано для того, что бы ты не писал в строке браузера 23.45.78.01 или что-то подобное, а ,например, сразу www.domenforum.net %)

Вроде ты это имел ввиду...
endorfine вне форума   Ответить с цитированием
Старый 30.04.2005, 02:29   #5
 
Регистрация: 21.02.2005
Сообщений: 255
Доменные сделки: 0
Реноме:
Одобрения
Спасибо (Отдано): 0
Спасибо (Получено): 0
сложная система млин
Dmitri вне форума   Ответить с цитированием
Старый 30.04.2005, 18:03   #6
 
Аватар для ostgur
 
Регистрация: 25.03.2005
Адрес: Япония
Сообщений: 1,242
Доменные сделки: 2
Реноме:
Одобрения
Спасибо (Отдано): 1
Спасибо (Получено): 2
А через панель управления доменами можно выбирать к какому NS-серверу ты хочешь подцепиться и как это сделать?
ostgur вне форума   Ответить с цитированием
Старый 24.06.2005, 17:14   #7
 
Регистрация: 21.02.2005
Сообщений: 255
Доменные сделки: 0
Реноме:
Одобрения
Спасибо (Отдано): 0
Спасибо (Получено): 0
Сообщение от ostgur
А через панель управления доменами можно выбирать к какому NS-серверу ты хочешь подцепиться и как это сделать?
можно... но нужно чтобы сам сервер тож смог принять твой домен
Dmitri вне форума   Ответить с цитированием
Старый 26.06.2005, 00:15   #8
 
Аватар для wolandino
 
Регистрация: 31.12.2004
Адрес: Russia, Astrakhan
Сообщений: 293
Доменные сделки: 5
Реноме: 216
Одобрения
Спасибо (Отдано): 0
Спасибо (Получено): 0
Отправить сообщение для wolandino с помощью ICQ
Саш, конечно позновательно, но меня в этом вопросе больше бы заинтересовала техническая сторона дела... если у кого-то будут вопросы относительно настройки DNS под *nix - обращайтесь
wolandino вне форума   Ответить с цитированием
Старый 28.07.2005, 20:22   #9
 
Регистрация: 15.06.2005
Сообщений: 11
Доменные сделки: 0
Реноме:
Одобрения
Спасибо (Отдано): 0
Спасибо (Получено): 0
Сообщение от Dmitri
сложная система млин
Нечего сложного нет если правильно всё сделать
mid вне форума   Ответить с цитированием
Ответ



Реклама

Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 
Опции темы
Закладки Добавить Тема в закладки

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 00:13. Часовой пояс GMT +4.