1. Від теорії до практики

Продовжуючи тему сайтостроения поговоримо про такий важливий аспект, як робота системи доменних імен - DNS. З налаштуванням і розташуванням DNS-зони пов'язані багато питань, що стосуються початкового розміщення, а також перенесення сайтів між різними серверами і хостингами. Розуміння принципів роботи системи доменних імен дозволяє з легкістю управляти власними доменами і пов'язаними з ними сайтами та іншими службами.

Що таке доменне ім'я? Для багатьох це синонім адреси сайту, наприклад, www.interface31.ru. Набираючи цю адресу ви твердо впевнені, що потрапите саме на цей сайт, а не куди-небудь ще. У той же час доменне ім'я може позначати не тільки сайт, але і сервер електронної пошти, обміну короткими повідомленнями або іншої іншої інтернет і мережевий сервіс. Доменні імена входять в доменні зони, які розташовані всередині один одного в ієрархічному порядку.

У загальному розумінні домен - це символьне ім'я, що дозволяє однозначно адресувати автономну область імен в мережі інтернет. І не тільки адресувати, але і дозволити будь-якому клієнту швидко знайти необхідний вузол, навіть не маючи ні найменшого уявлення про його розміщення. Можна без перебільшення сказати, що система DNS - основа сучасної мережі інтернет в тому вигляді, в якій ми всі її знаємо і звикли.

Система DNS є глобальною і має сувору ієрархію. Розглянемо наступну схему:

Верхнім рівнем ієрархії є кореневої домен, що позначається точкою, який містить інформацію про домени першого рівня, наприклад, ru, сom, org і т.п. Роботу кореневої зони забезпечують 13 кореневих серверів, розташованих по всьому світу і постійно повторює навколишньої свої дані між собою. Насправді кореневих серверів більше, але особливості протоколу дозволяють вказати тільки 13 вузлів верхнього рівня, поетом масштабованість і відмовостійкість системи забезпечується дзеркалами кожного кореневого сервера.

Домени першого рівня є звичними нам доменними зонами і можуть управлятися як національними, так і міжнародними організаціями і мати свої умови використання. Кожна доменна зона першого рівня дозволяє розміщувати необмежену кількість доменів другого рівня, які знайомі кожному користувачеві Інтернету як адреси сайтів.

У свою чергу домени другого рівня теж є доменними зонами і дозволяють розміщувати в себе домени третього рівня, в які, як в матрьошку, поміщати домени четвертого, п'ятого і т.д. рівнів. Для того, щоб можна було однозначно визначати вузли, що знаходяться в різних зонах, введено поняття повністю певне ім'я домену (FQDN, Fully Qualified Domain Name), яке включає в себе всі імена батьківських доменів в ієрархії DNS. Наприклад, для нашого сайту FQDN буде: interface31.ru. Саме так, із закінченням на точку, що позначає кореневу зону.

Це дуже важливий момент. У повсякденному використанні завершальну крапку прийнято відкидати, але в записах DNS відсутність останньої точки позначає, що дане доменне ім'я належить поточної доменній зоні, тобто DNS-сервер додасть до такого імені власну доменну зону і все вищі зони аж до кореня.

Наприклад, на нашому сервері в зоні interface31.ru ми додаємо запис типу CNAME, яка буде вказувати на сторонній сервер, скажімо, Яндекс-пошти. Правильно запис має виглядати так:

mailIN CNAMEdomain.mail.yandex.net.

В даному випадку ім'я mail не є FQDN і буде доповнено до mail.interface31.ru. , Якщо ж ми забудемо поставити крапку в кінці імені домена Яндекса, то це ім'я також не сприйматиметься як FQDN і має бути доповнене до повного імені домену. Нижче показана неправильна запис:

mail IN CNAME domain.mail.yandex.net

Непідготовленим поглядом різницю помітити складно, але замість веб-інтерфейсу пошти Яндекса така конструкція відправить нас на неіснуючу адресу: domain.mail.yandex.net.interface31.ru.

Ще один момент. Всі записи для доменної зони вносяться адміністраторами зон на власних DNS-серверах, яким чином дані записи стають відомі системі DNS? Адже ми ж не сповіщаємо вищі DNS-сервера, що змінили якусь запис.

Будь-яка DNS-зона містить записи тільки про вхідні в неї вузлах і дочірніх зонах. Інформація про вузли нижчої зони зберігається на її власних серверах. Це називається делегуванням і дозволяє знизити навантаження на кореневі сервери і надати необхідну автономію власникам дочірніх доменних зон.

Отже, ви купили домен, скажімо, example.org, після чого ви повинні його делегувати, тобто вказати сервера імен (DNS-сервера), які будуть містити записи даної файлової зони. Це можуть бути як ваші власні сервера, так і публічні сервіси, наприклад, DNS Яндекса.

В цьому випадку в доменній зоні org буде додано запис:

example IN NS dns1.yandex.net.

Яка буде вказувати, що всі записи цієї зони розташовані на сервері dns1.yandex.net. За правилами, кожна доменна зона повинна мати не менше двох NS-серверів, розташованих в різних подсетях. На практиці часто обходяться одним сервером, набуваючи для нього два IP-адреси з різних діапазонів.

Тепер розберемо, яким чином відбувається пошук необхідної нам DNS-записи і чому запис, зроблений на вашому сервері, дозволяє потрапити на ваш сайт відвідувачам з будь-якої точки земної кулі.

Припустимо, користувач хоче відвідати популярний ресурс Яндекс Маркет, він набирає в адресному рядку браузера відповідне ім'я сайту і натискає кнопку Enter. Для того, щоб відобразити користувачеві вміст сторінки браузер повинен відправити запит обслуговуючому сайт веб-сервера, а для цього потрібно знати його IP-адресу. Тому браузер звертається до DNS-клієнта з метою дізнатися, яку адресу відповідає введеному користувачем доменному імені.

У свою чергу DNS-клієнт перевіряє записи у файлі hosts, потім в локальному кеші і, не знайшовши там потрібних записів, передає запит зазначеного в мережевих налаштуваннях DNS-сервера. Швидше за все це буде локальний кешуючий DNS-проксі, наприклад, dnsmasq або локальний DNS-сервер підприємства. Дані рішення зазвичай не є повноцінними серверами глобальної системи DNS і не входять в неї, обслуговуючи лише локальну зону і кешіруя DNS-запити, тому такий запит, якщо даних не виявляється в кеші, передається вищестоящому DNS-сервера, як правило це сервер провайдера.

Отримавши запит, сервер провайдера перевірить власні записи, потім власний кеш, і, якщо результат буде знайдений, повідомить його клієнту, в іншому випадку сервер змушений буде вдатися до рекурсії - пошуку в глобальній системі DNS. Щоб краще зрозуміти механізм даного процесу ми підготували наступну схему:

Отже, клієнт відправляє DNS-запит серверу провайдера з метою дізнатися адресу домену market.yandex.ru, сервер провайдера не має подібної інформації, тому звертається до одного з кореневих серверів, передаючи йому запит. Кореневий сервер також не має потрібних записів, але відповідає, що знає сервер, який відповідає за зону ru - a.dns.ripn.net. Разом з такою назвою кореневий сервер може відразу повідомити його IP-адреса (і в більшості випадків повідомить), але може і не зробити цього, якщо не має такої інформації, в такому випадку, перед тим як звернутися до даного сервера, потрібно буде виконати ще один рекурсивний запит, тільки вже для визначення його імені.

З'ясувавши адресу сервера, що відповідає за зону ru, сервер провайдера передасть запит йому, але даний сервер також не має потрібних записів, але повідомить, що за зону yandex відповідає сервер ns1.yandex.ru і обов'язково повідомить його адресу. Інакше рекурсию завершити не вдасться, так як за зону yandex відповідає сервер, що знаходиться в зоні yandex. Для цього у вищій зоні, крім NS-записи про обслуговуючі зону серверах імен, створюється "пов'язана" А-запис, яка дозволяє дізнатися адресу такого сервера.

Нарешті, відправивши запит серверу, обслуговуючому зону yandex, сервер провайдера отримає адресу шуканого домену і повідомить його клієнту. Також він помістить отриманий результат в кеш на час, передбачений значенням TTL в SOA-запису цього домену. На практиці, так як рекурсивні запити вельми затратні, час кешування записів у провайдерів може ігнорувати значення TTL домену і досягати значень від двох-чотирьох годин до декількох днів або навіть тижнів.

Тепер розглянемо ще один момент. Запити можуть бути рекурсивними або нерекурсивними. Рекурсивний запит передбачає отримання готової відповіді, тобто IP-адреси або повідомлення що домен не існує, чи не делегований і т.п. Нерекурсивний запит передбачає відповідь тільки про ту зоні, за яку відповідає даний сервер або повернення помилки.

Так як рекурсивні запити є досить ресурсоємними більшість серверів мережі DNS обробляють рекурсивні запити нерекурсівние. Або можуть робити це вибірково, наприклад, DNS-сервера провайдера виконують рекурсивні запити тільки для своїх клієнтів, а решта нерекурсівние.

У нашому випадку клієнт послав сервера провайдера рекурсивний запит, який, в свою чергу, послідовно відправляв нерекурсівние запити поки не знайшов необхідний сервер, який дав необхідний відповідь. При цьому в кеш сервера провайдера поміщаються не тільки результати користувальницького запиту, але і результати проміжних запитів, що дозволяє виконувати наступні такі запити нерекурсівние або з мінімальною кількістю запитів.

Наприклад, якщо користувач після відвідування Яндекс.Маркет вирішить скористатися поштовим сервісом, то сервер відразу направить запит до ns1.yandex.ru, так як вже знає, який сервер містить записи для зони yandex.

Від теорії до практики

Коли ви купуєте у реєстратора домен, вам буде запропоновано його делегувати, тобто вказати DNS-сервера, на яких буде розташована доменна зона. Це можуть бути сервера реєстратора (зазвичай безкоштовно), сервера хостера, публічні DNS-сервіси або власні сервера імен, якщо він буде розташований в цій же доменній зоні, то вам буде потрібно також вказати IP-адреси. Наприклад, так виглядає вікно делегування домену в одного відомого реєстратора:

Що саме туди вказувати? Це залежить від того, де і як ви будете розміщувати свій сайт. Якщо ви використовуєте віртуальний хостинг, то всі необхідні записи створюються хостером автоматично, при додаванні в панелі управління хостингом вашого сайту, все що вам треба - це делегувати домен на NS-сервера хостера, тобто вказати їх в даному вікні. Цей спосіб добре підходить початківцям, завдяки своїй простоті, але є і зворотна сторона, можливість управління DNS-зоною з боку користувача відсутня або мінімальна. Крім того, на віртуальному хостингу IP-адреса сайту може бути змінений адміністраторами без повідомлення користувача, тому, якщо ви не хочете використовувати NS-сервера хостера, то це питання слід обов'язково обговорити з техподдержкой.

Якщо ви переносите сайт до іншого хостера, то вам буде потрібно перенести сайт і поміняти у реєстратора сервера імен старого хостера на сервера нового. Але врахуйте, що інформація в кеші DNS-серверів оновлюється не миттєво, а, як мінімум, після закінчення значення TTL-домену, тому протягом деякого часу ваш сайт може бути доступний ще за старою адресою. Якщо вам треба терміново з ним працювати, то можете, не чекаючи оновлення DNS-кешу вашого провайдера, додати в файл hosts запис такого змісту:

1.2.3.4 example.com

Де 1.2.3.4 і example.com відповідно новий IP-адресу та ім'я вашого домену.

Якщо у вас свій VPS або ви хочете повністю контролювати доменну зону, то слід скористатися серверами реєстратора або публічними сервісами. Створення власного сервера імен, на наш погляд, не виправдує себе затія, якщо тільки ви не робите власний хостинг.

В цьому випадку вам потрібно створити, як мінімум, дві А-записи, які будуть вказувати на веб-сервер обслуговує сайт в даному домені:

@ IN A 1.2.3.4
www IN A 1.2.3.4

Символ "собачки" в DNS-записах позначає сам домен, крім того обов'язково слід створити запис для поддомена www, щоб користувачі, які набрали адресу сайту з www, також могли отримати до нього доступ.

Ми не будемо розглядати додавання записів для електронної пошти, про це можна прочитати в нашій статті: Поштовий сервер для початківців. Налаштовуємо DNS зону.

При перенесенні сайту вам буде потрібно змінити тільки IP-адреси в A-записах і дочекатися поновлення DNS інформації. Зазвичай, це самий неприємний момент - начебто все зроблено, але нічого змінити ви не можете, залишається тільки чекати. Але якщо виконати деякі рекомендації, то даний процес можна провести максимально безболісно і непомітно для відвідувачів.

Перш за все змініть значення TTL в SOA-запису. За замовчуванням воно дорівнює декільком годинам і саме стільки вам доведеться чекати поновлення вашої запису в кеші DNS-серверів. Щоб дізнатися поточне значення TTL можна виконати команду, вказавши потрібне доменне ім'я:

nslookup -typr = soa interface31.ru

У нашому випадку це 4 години:

Тому заздалегідь, не менше 4 годин (старе значення TTL) до планованого перенесення, змініть значення TTL на більш низьке, наприклад, 900 (15 хвилин). Потім переведіть свій сайт в режим "тільки читання" і перенесіть його на новий сервер. Вимикати або переводити на техобслуговування сайт не слід, він може і повинен залишатися доступним. Але ви повинні виключити зміну і додавання інформації користувачами, тобто заборонити реєстрацію, коментування, розміщення замовлень і т.п. Також не забудьте розмістити на видному місці повідомлення про технічні роботах і приблизний термін їх завершення.

Для того, щоб працювати з новим сервером, не змінюючи DNS-записи, додайте потрібний рядок в файл hosts. Розмістивши сайт на новому майданчику і переконавшись в його нормальній роботі змініть DNS-записи, тепер уже через 15 хвилин перші користувачі почнуть відвідувати ваш сайт на новому сервері. Працездатність старого сервера потрібно підтримувати ще деякий час, в ідеалі до тижня, так як не всі провайдери використовують значення TTL з SOA-запису для оновлення кешу, для зменшення навантаження на обладнання можуть бути використані власні настройки.

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

Ми розглянули найпростішу схему, але на практиці, крім сайту, зазвичай є ще офісна мережа, багато ресурси якої повинні бути також доступні ззовні. Розглянемо наступну схему:

У нас є публічні сервера для сайту і електронної пошти і офісна мережа, для якої ми виділили піддомен office. Якщо з поштою і веб-сервером особливих питань немає, то з офісною зоною є варіанти. Зазвичай локальна зона обслуговується власним DNS і ніяк не пов'язана з материнською зоною. Для глобальної системи DNS зона office.example.com не існує, але існує однойменний хост. Це виправдано, якщо мережа підприємства знаходиться за NAT і її вузли мають тільки сірі адреси, а доступ ззовні здійснюється тільки до шлюзу, на який проброшени відповідні порти від внутрішніх вузлів.

В цьому випадку DNS записи зони example.com можуть виглядати наступним чином:

@ IN A 1.2.3.4
www IN A 1.2.3.4
mail IN A 1.2.3.5
office IN A 5.6.7.8

Але виникає деяка складність, всередині мережі клієнти звертаються до мережевих сервісів по внутрішнім іменами: corp.office.example.com або rdp.office.example.com, які вказують на внутрішні "сірі" адреси ". Однак за межами локальної мережі дозволити IP- адреса для таких імен не представляється можливим, тому що містить їх зони для глобальної системи DNS не існує. Вийти з положення дозволяє механізм, званий Split-DNS, який дозволяє віддавати різні результати в залежності від стану клієнта.

У локальній мережі DNS-запити клієнтів обслуговує локальний сервер, які має відповідні записи, за її межами запити будуть направлені сервера, який обслуговує зону example.com. При цьому всі корпоративні ресурси, які в локальній мережі представлені різними серверами, ззовні доступні по єдиному адресою: office.example.com. Тому саме час згадати про записи псевдоніма або CNAME. Даний запис дозволяє пов'язувати з реальним ім'ям хоста додаткові мнемонічні імена або псевдоніми. При цьому врахуйте, що використовувати в інших записах псевдонімів неприпустимо. У нашому випадку слід додати записи:

corp.office IN CNAME office.example.com.
rdp.office IN CNAME office.example.com.

Тепер клієнт, незалежно від свого місця розташування, може використовувати для доступу до ресурсів одне і теж ім'я, але результат отримувати при цьому буде різний. У локальній мережі він отримає реальну адресу сервера і підключиться безпосередньо, а за її межами буде спрямований на шлюз мережі.

Також записи типу CNAME можна використовувати для перенаправлення за межі обслуговується доменної зони. Головна умова - CNAME запис повинна вказувати на реальне ім'я в форматі FQDN.

Ще одне! Застосування псевдонімів - це СКОРОЧЕННЯ адреси. Пріпустімо, в якості поштового сервера для Всього домену example.com ми Хочемо використовуват сервер, Який розташованій в московському офісі и має адресу mail.office.msk.example.com, погодьтеся, Виглядає НЕ дуже Привабливий. Набагато зручніше було б адреса виду mail.example.com, немає нічого простішого, додамо наступний запис:

mail IN CNAME mail.office.msk.example.com.

Але пам'ятайте, що в інших ресурсних записах слід використовувати тільки реальні імена, тому такий запис буде невірною:

example.com. IN MX 10 mail

Правильно буде так:

example.com. IN MX 10 mail.office.msk

Наостанок поговоримо про делегування доменних зон. В наведеному вище прикладі ми розглянули ситуацію, коли всередині домену різним підрозділам виділені свої піддомени, так як у кожного підрозділу є своя інфраструктура, то є сенс делегувати їм управління власними доменними зонами. Для цього в зоні example.com слід розмістити NS і пов'язану з нею A-запис для кожної зони. например:

msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.
ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8

Тепер при зверненні за адресою, скажімо mail.office.msk.example.com сервера імен зони example.com видаватимуть ім'я та адресу сервера, який обслуговує зону msk.example.com. Це дозволяє адміністраторам зони самостійно вносити необхідні зміни, не зачіпаючи при цьому функціонування вищої зони і не звертаючись до її адміністраторам з будь-якого питання, що вимагає зміни записів.