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

1. Вимога дотримання заданого часу відгуку і забезпечення передбаченої в угоді про рівень обслуговування...
2. Не думай про секунди звисока ...
3. Спроба - не катування ...
4. Що таке добре і що таке погано...
5. Сухий Залишок
6. література

Вимога дотримання заданого часу відгуку і забезпечення передбаченої в угоді про рівень обслуговування надійності, робить вельми актуальним питання про розміщення серверів доменних імен в Мережі.

Серед ІТ-фахівців все більш популярним сьогодні стає питання розробки систем розповсюдження контенту (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 секунд досить велике для того, щоб браузер користувача багато разів звертався до серверів.

Що таке добре і що таке погано...

Який час відгуку 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 припускають «однаковість» авторитативні серверів доменів.

Сухий Залишок

Слід визнати «прийнятним» час завантаження від 1 до 5 секунд, а в якості мети, яку бажано досягти при розробці сторінок сайтів, - 1 секунда до появи першого символу на екрані користувача. В якості мети при розміщенні DNS-серверів слід визнати такий час пошуку в системі DNS, яке не перевищувало б 0,15 с. Відповідно до вімірів годині відгуку серверів доменних імен другого уровня в зоне RU, более половини серверів задовольняють ЦІМ умів.

Для надійного забезпечення поиска своих ресурсов в мережі слід НЕ обмежуватіся двома авторітатівні серверами, а збільшити їх число до трьох, Щоб не опінітіся в ситуации прізупінення делегування.

«Добре» розміщувати потрібно не тільки первинний (master) сервер зони, але і все авторитативні сервери - несправність будь-якого з них загрожує припиненням делегування, а крім того, зовсім не обов'язково, що resolver-сервер користувача вибере при пошуку первинний сервер.

У ІТ-громадськості ще немає чіткого розуміння того, чим конкретно (збитки, втрачені користувачі, чітко виміряні неприпустимі затримки і т.п.) може загрожувати неправильне розміщення DNS-сервера. Для Рунета ніхто не розраховував часи відгуку на запит ресурсів, не вивчав складові часу відгуку, і вплив всього цього на бізнес. Тим часом, наприклад, при зміні маршрутизації в кінці минулого року трьома провідними російськими провайдерами та збільшенні RTT деякі бізнесмени від Internet втратили користувачів і, відповідно, понесли збитки, але їх вимірювань і кореляцій ніхто не робив. На Заході роботи, присвячені виміру RTT тим же методом, що і розглянуті в даній статті, були проведені в кінці минулого року [18]. Передбачається, що це допоможе судити про вплив RTT на ефективність роботи Мережі, однак поки ці роботи ще не завершені. У загальному випадку, це досить серйозна проблема, яка зачіпає оцінку всього обсягу трафіку, що надається вітчизняними провайдерами.

література

1. Uniform Resource Identifiers (URI): Generic Syntax. RFC-2396, 1998. ( http://www.ietf.org/rfc/rfc2396.txt?number=2396 )
2. Role of the Domain Name System (DNS). RFC-3467.2003 ( http://www.ietf.org/rfc/rfc3467.txt?number=3467 )
3. P. Mockapetris. Domain Names - Concepts and Facilities. RFC-1034, 1987. ( http://www.ietf.org/rfc/rfc1034.txt?number=1034 )
4. P. Mockapetris. Domain Names - Implementation and Specification. RFC-1035. 1987. ( http://www.ietf.org/rfc/rfc1035.txt?number=1035 )
5. 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.
6. Галицький Є.Б. Опитування "Інтернет в Росії". Випуск 3. Весна 2003. ФОН. ( http://www.fom.ru/reports/frames/o0316061.html )
7. Аудиторія Рунета за методикою SpyLOG-монітор. 2003. Апрель. ( http://gs.spylog.ru/interesting.phtml?id=53&PHPSESSID=817c3cea3231167985d03a45df37d2dc )
8. Selection and Operation of Secondary DNS Servers. RFC-2182. 1997. ( http://www.ietf.org/rfc/rfc2182.txt?number=2182 )
9. Регламент реєстрації доменів в домені RU. 19.08.2002. ( http://www.nic.ru/dns/contract/sup1_1_ru.html )
10. Bob Bailey. Acceptable Computer Response Times. UI Design Update Newsletter - April, 2001. ( http://www.humanfactors.com/downloads/apr012.htm )
11. Bob Bailey. Improving User Performance. UI Design Update Newsletter - June, 2000. ( http://www.humanfactors.com/downloads/june00.asp )
12. Тимофій Бокарьов. Енциклопедія Інтернет-реклами. (Http://book.promo.ru/book/)
13. Unix Manual Page for resolv.conf. ( http://www.scit.wlv.ac.uk/cgi-bin/mansec?4+resolv.conf )
14. The dig Manual Page. ( http://www.stopspam.org/usenet/mmf/man/dig.html )
15. 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.
16. 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 )
17. Статистика реєстрації та делегування доменів в зоні RU на 2003-06-16 ( http://stat.nic.ru/2003/06/16/stats-20030616.shtml )
18. 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 )

Павло Храмцов ( [email protected] ) - співробітник РНЦ «Курчатовський інститут» (Москва)