Відмінності між версіями «DNS»

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук
(Записи DNS)
 
(не показана одна проміжна версія 4 учасників)
Рядок 1: Рядок 1:
Протокол '''DNS''' (Domain Name Service - служба доменних імен) забезпечує пошук імен хостів, використовуючи розподілену по мережних серверах імен базу даних.
+
<center>
 +
[[Файл:DomainNameSystem.jpg]]
 +
</center>
  
Протокол DNS виконує дві основні ''функції''. Він дозволяє клієнтським комп'ютерам запитувати DNS-сервер про IP-адресу або ім'я якого-небудь хоста в мережі, а також дозволяє робити обмін інформацією між базами даних серверів DNS. У цьому протоколі використовується стандартний формат типу "запит-відповідь", де клієнт посилає пакет запиту, і сервер відповідає або пакетом з інформацією, отриманою з бази даних, або повідомленням про помилку, у якому вказується причина відмови в обробці запиту. У своїй роботі цей протокол використовує порт 53 і добре відомі протоколи — TCP або UDP. Причому останнім часом UDP став більш розповсюдженим методом транспортування пакетів по мережі Internet. Пакет DNS складається з п'яти полів: заголовка, питання, відповіді, повноважень і поля додаткової інформації.
+
{|class="wikitable" width=300px align=right
 +
! Назва:
 +
| Domain Name Server
 +
|-
 +
! Рівень (по моделі OSI):
 +
| Прикладний
 +
|-
 +
! Сімейство:
 +
| TCP/IP
 +
|-
 +
! Порт/ID:
 +
| 53/TCP, 53/UDP
 +
|-
 +
! Призначення протоколу:
 +
| Розширення доменних імен
 +
|-
 +
! Специфікація:
 +
| RFC 1034 , RFC 1035 / STD 13
 +
|-
 +
! Основні реалізації (клієнти):
 +
| Вбудована у всі мережеві ОС
 +
|-
 +
! Основні реалізації (сервери):
 +
| BIND, PowerDNS або Microsoft DNS Server
 +
|}
  
Формат повідомлень DNS показаний на малюнку.
+
'''DNS''' (англ. ''Domain Name System'' - система доменних імен) - це розподілена комп'ютерна система для отримання інформації про домени. Найчастіше використовується для отримання IP-адреси по імені хоста (комп'ютера або пристрою), отримання інформації про маршрутизацію пошти , обслуговуваних вузлах для протоколів у домені (SRV-запис).
<center>[[Image:DNS.jpg]]</center>
+
  
'''''Ідентифікатор''''' - 16-бітове поле для позначення відповідності між запитами і відгуками.
+
Розподілена база даних DNS підтримується за допомогою ієрархії DNS-серверів, взаємодіючи за певним протоколом.
  
'''''Q''''' - 1-бітовий прапор запиту (query).
+
Основою DNS є представлення про ієрархічну структуру доменного імені та зонах.
 +
*Кожен сервер, відповідаючи за ім'я, може делегувати відповідальність за подальшу частину домену іншому серверу (з адміністративної точки зору - іншій організації або людині), що дозволяє покласти відповідальність за актуальність інформації на сервери різноманітних організацій (людей), відповідаючи тільки за «свою» частину доменного імені.
  
'''''Запит''''' - 4-бітовий опис типу повідомлення:
+
*Зона (zone) це окремо адмініструються частина дерева DNS. Наприклад, домен другого рівня '''''noao.edu''''' це окрема зона. Багато доменів другого рівня поділені на менші зони. Наприклад, університет може поділити свою зону на підзони по факультетах, а компанія може поділити себе на зони за принципом поділу на філії або відділи.
    0 стандартний запит (адреса по імені).
+
    1 зворотний запит (ім'я за адресою).
+
    2 запит стану сервера.
+
  
'''''A (Authoritative Answer)''''' - 1-бітовий прапор, що показує відгук від уповноваженого (authoritative) сервера імен.
+
== Ключові характеристики DNS ==
 +
DNS володіє наступними характеристиками:
 +
* '''''Розподільність адміністрування'''''. Відповідальність за різні частини ієрархічної структури несуть різні люди та організації.
 +
* '''''Розподільність збереження інформації'''''. Кожен вузол мережі в обов'язковому порядку повинен зберігати тільки ті данні, які належать до його зону відповідальності і (можливо) адреси кінцевих DNS-серверів.
 +
* '''''Кеширування інформації'''''. Вузол може зберігати деяку кількість даних не із власної зони відповідальності для зменшення навантаження на мережу.
 +
* '''''Ієрархічна структура''''', у якій усі вузли об'єднані у дерево, а кожен вузол може або самостійно визначати роботу нижчих за ієрархію вузлів, або делегувати ( передавати) їх іншим вузлам.
 +
* '''''Резервування'''''. За збереження та обслуговування своїх вузлів (зон) відповідають (зазвичай) декілька серверів, розподілених як фізично, так і логічно, що забезпечує зберігання даних та продовження роботи навіть у разі виходу з ладу одного з вузлів.
  
'''''T (Truncation)''''' - відкидання. 1-бітовий прапор, що говорить про відкидання повідомлення.
+
DNS важлива для роботи мережі Інтернет, так як для з'єднання з вузлом необхідна інформація про його IP-адресу, а для людей легше запам'ятати символьні (зазвичай змістовні) адреси, ніж послідовність цифр IP-адрес. У деяких випадках це дозволяє використовувати віртуальні сервери, наприклад, HTTP-сервери, розрізняючи їх по імені запиту. Спочатку перетворення між доменними та IP-адресами відбувалося з використанням спеціального текстового файлу '''hosts''', який складався централізовано та автоматично відправлявся на кожну з машин у своїй локальній мережі. З ростом Мережі виникла необхідність в ефективному, автоматизованому механізмі, яким і стала DNS.
  
'''''R''''' - 1-бітовий прапор, який встановлюэться для дозволу запиту рекурсивним шляхом.
+
DNS була розроблена Полом Мокапетрісом у 1983 році; оригінальне опис механізмів роботи міститься в стандартах RFC 882 та RFC 883. У 1987 публікація RFC 1034 і RFC 1035 змінила специфікацію DNS і скасувала RFC 882 та RFC 883 як застарілі.
  
'''''V''''' - 1-бітовий прапор підтримки рекурсивного сервісу.
+
== Додаткові можливості ==
 +
* Підтримка динамічних оновлень
 +
* Захист даних ('''DNSSEC''') і транзакцій ('''TSIG''')
 +
* Підтримка різноманітних типів інформації (SRV-записи)
  
'''''B''''' - 3-бітове поле, зарезервоване для використання в майбутньому (0).
+
== Термінологія і принципи роботи ==
 +
Основна область застосування DNS це перетворення імені хоста (Під "хостом" мається на увазі комп'ютер або сервер, підключеної до локальної мережі, або інтернету.) в IP-адресу та надання даних про маршрутизації пошти.  
  
'''''Rcode'''''  -
+
Принцип роботи.
        Код відгуку - 4-бітове поле, що встановлюэться сервером імен для позначення стану запиту:
+
Коли користувач запускає веб-браузер в вводить назву домену сайту, його ПК відправляє запит до DNS-сервера інтернет-провайдера для отримання IP-адреси, на якому знаходиться домен (1).
      0 немає помилок.
+
Якщо DNS-сервери провайдера  не виявляють у своєму кеші інформації про запитуваній сайт, то відправляють запит на кореневі DNS-сервери (2).
      1 неможливо інтерпретувати запит через формальну помилку.
+
      2 обробка неможлива через збій на сервері.
+
      3 запитане ім'я не існує. 
+
      4 непідтримуваний тип запиту.
+
      5 відмова від виконання запиту.
+
  
'''''Лічильник питань''''' - 16-бітове поле, що містить число записів у розділі питань.
+
Кореневий DNS-сервер шукає в своїй базі даних інформацію про сервери імен хостинг-провайдера, на яких присутній цей сайт. Далі, він повідомляє з кешируючого DNS-сервера провайдера (3).
  
'''''Лічильник відповідей''''' - 16-бітове поле, що містить число записів про ресурси в розділі відповідей.  
+
Після того, як кешуючий DNS-сервер провайдера отримує інформацію про сервери імен провайдера він опитує будь-який з них (4) і, у разі отримання позитивного результату отримання IP-адреси (5), поміщає в кеш (Кешування використовується для того, щоб знизити як навантаження на інтернет-канали, так і для прискорення отримання результату запиту).
 +
Після цього DNS-сервер провайдера передає IP-адреса браузеру користувача, який здійснив запит сайту (6).
  
'''''Лічильник Authority''''' - 16-бітове поле, що визначає число записів про ресурси сервера імен у розділі authority (повноваження).
+
І вже після цього браузер, отримавши IP-адреса запитуваного сайту, переходить на сам сайт (7 і 8).
 +
<center>
 +
[[Файл:workDNS.jpg]]
 +
</center>
  
'''''Лічильник доповнень''''' - 16-бітове поле, що визначає число записів про ресурси сервера імен у додатковому розділі.
+
'''Ключовими поняттями DNS є:'''
 +
* '''''Домен''''' (англ. domain - область) - вузол в дереві імен, разом з усіма підлеглими йому вузлами (якщо такі є), тобто іменована ''гілка'' або ''піддерево'' в дереві імен. Структура доменного імені зображає порядок проходження вузлів в ієрархії; доменне ім'я читається зліва направо від молодших доменів до доменів вищого рівня (в порядку підвищення значимості), кореневим доменом всієї системи є крапка ('.'), нижче йдуть домени першого рівня (географічні або тематичні ), потім - домени другого рівня, третього і т. д. (наприклад, для адреси '''ua.wikipedia.org''' домен першого рівня - '''org''', другого '''wikipedia''', третього '''ua'''). На практиці крапку в кінці імені часто опускають, але вона буває важлива у випадках поділу між відносними доменами і FQDN (англ. ''Fully Qualifed Domain Name'', повністю визначене ім'я домену).
 +
* '''''Піддомен''''' (англ. subdomain) - підлеглий домен. (Наприклад, '''wikipedia.org''' - піддомен домену '''org''', а '''ua.wikipedia.org''' - домену '''wikipedia.org'''). Теоретично такий розподіл може досягати глибини 127 рівнів, а кожна мітка може містити до 63 символів, поки загальна довжина разом з точками не досягне 254 символів. Але на практиці реєстратори доменних імен використовують більш суворі обмеження. Наприклад, якщо у вас є домен виду '''mydomain.ru''', ви можете створити для нього різні піддомени виду '''mysite1.mydomain.ru''', '''mysite2.mydomain.ru''' і т. д.
 +
* '''''Ресурсний запис''''' - одиниця зберігання і передачі інформації в DNS. Кожний ресурсний запис має ім'я (тобто прив'язаний до певного доменного імені, вузлу в дереві імен), тип і поле даних, формат і зміст якого залежить від типу.
 +
* '''''Зона''''' - частина дерева доменних імен (включаючи ресурсні записи), що розміщується як єдине ціле на деякому сервері доменних імен (DNS-сервер), а частіше - одночасно на декількох серверах. Метою виділення частини дерева в окрему зону є передача відповідальності за відповідний Домен іншій особі або організації, так зване Делегування. Як зв'язкова частина дерева, зона всередині теж являє собою дерево. Якщо розглядати простір імен DNS як структуру із зон, а не окремих вузлів / імен, теж виходить дерево; виправдано казати про батьківські і дочірні зони, про старших і підлеглих. На практиці, більшість зон 0-го і 1-го рівня ('.', '''ru''', '''com''', ...) складаються з єдиного вузла, якому безпосередньо підпорядковуються дочірні зони. У великих корпоративних доменах (2-го і більше рівнів) іноді зустрічається утворення додаткових підлеглих рівнів без виділення їх у дочірні зони.
 +
* '''''Делегування''''' - операція передачі відповідальності за частину дерева доменних імен іншій особі або організації. За рахунок делегування в DNS забезпечується розподільність адміністрування та зберігання. Технічно делегування виражається у виділенні цієї частини дерева в окрему зону, та розміщення цієї зони на DNS-сервер, керованому цією особою чи організацією. При цьому в батьківську зону включаються «склеюючи» ресурсні записи ('''NS''' і '''А'''), що містять покажчики на DNS-сервера дочірньої зони, а вся інша інформація, що відноситься до дочірньої зоні, зберігається вже на DNS-серверах дочірньої зони.
 +
* '''''[[DNS сервер|DNS-сервер]]''''' - спеціалізоване ПО для обслуговування DNS, а також комп'ютер, на якому це ПЗ виконується. DNS-сервер може бути відповідальним за певні зони і / або може перенаправляти запити серверам, що знаходяться вище за ієрархією.
 +
* '''''[[DNS клієнт|DNS-клієнт]]''''' - спеціалізована бібліотека (або програма) для роботи з DNS. У ряді випадків DNS-сервер виступає в ролі DNS-клієнта.
 +
* '''''Авторитетність''''' (англ. authoritative) - ознака розміщення зони на DNS-сервері. Відповіді DNS-сервера можуть бути двох типів: ''авторитетні'' (коли сервер заявляє, що сам відповідає за зону) і ''неавторитетний'' (англ. Non-authoritative), коли сервер обробляє запит, і повертає відповідь інших серверів. У деяких випадках замість передачі запиту далі DNS-сервер може повернути вже відоме йому (за запитами раніше) значення (режим кешування).
 +
* '''''[[DNS запити|DNS-запит]]''''' (англ. DNS query) - запит від клієнта (або сервера) серверу. Запит може бути ''рекурсивним'' або ''нерекурсивним''.
  
== Правила формування імен ==
+
Система DNS містить ієрархію DNS-серверів, відповідну до ієрархії зон. Кожна зона підтримується як мінімум одним авторитетним сервером DNS (від англ. ''Authoritative'' - авторитетний), на якому розташована інформація про домен.
  
Повне доменне (від англ. ''domain'') іммашини (FQDN, Fully Qualified Domain Name) можна розбити на дві частини&nbsp;— ім'я області-домена та власне ім'я машини. Наприклад, ''m30.ziet.zhitomir.ua''&nbsp;— повна доменне ім'я машини ''m30'', яка знаходиться у домені ''ziet.zhitomir.ua''.
+
Імта IP-адреса не тотожні - одина IP-адреса може мати безліч імен, що дозволяє підтримувати на одному комп'ютері безліч веб-сайтів (це називається віртуальний хостинг). Зворотне теж справедливо - одному імені можна порівнювати безліч IP-адрес: це дозволяє створювати балансування навантаження.
  
За порядок у доменах, як правило, відповідає певний комп'ютер, користувачі-адміністратори якого слідкують за тим, щоб не було, наприклад, різних машин з однаковими ІР-адресами. Наприклад, відповідальність за область-домен ''ziet.zhitomir.ua'' покладається на машину ''alpha.ziet.zhitomir.ua'' Ця влада делегується зверху вниз від машини ''ns.lucky.net'', яка відповідає за домен ''zhitomir.ua''. В свою чергу, відповідальність за область ua делегована машині зверху від так званих кореневих серверів (''root server'').
+
Для підвищення стійкості системи використовується безліч серверів, що містять ідентичну інформацію, а в протоколі є засоби, що дозволяють підтримувати синхронність інформації, розташованої на різних серверах. Існує 13 кореневих серверів, їх адреси практично не змінюються.
  
Всю цю систему можна уявити у вигляді перевернутого дерева. Нижче наведений список імен доменів верхнього рівня (далеко не повний). Повний список географічних областей, в основному, відповідає двобуквені ISO-коди країн|двобуквеним ISO-кодам країн і його можна знайти, наприклад, на WWW-сервері ISOC (http://www.isoc.org).
+
=== [[Рекурсія]] ===
  
Необхідно розрізняти доменне ім'я, та поштову адресу. В поштовій адресі повинен бути знак «@», якій розділяє поштову адресу на доменне ім'я та ім'я поштової скриньки.
+
Терміном '''Рекурсія''' в DNS означають алгоритм поведінки '''DNS- сервера''', при якому сервер виконує від імені клієнта повний пошук потрібної інформації в усій системі DNS, при необхідності звертаючись до іншим '''DNS- серверам'''.
  
Коли мережа Інтернет була молода та невелика, таблиці відповідності імен та адрес зберігалися у звичайному текстовий файл|текстовому файлі, який періодично просто розсилався всім учасникам електронною поштою. Після того, які кількість машин значно збільшилася, така схема перестала ефективно працювати і програмісти Університет Каліфорнії, Берклі|університету штату Каліфорнія в Берклі спроектували і написали програму BIND (Berkeley Internet Name Domain), яка відповідає на запити машин користувачів, які стосувалися імен та ІР-адресу.
+
'''DNS- запит''' може бути ''рекурсивним'' - що вимагає повного пошуку, - і ''нерекурсивним''  (чи ''ітеративним'') - що не вимагає повного пошуку.
  
Служба імен DNS (Domain Name System)&nbsp;— це розподілена база даних доволі простої структури. Для початкового знайомства можна вважати, що це кілька таблиць, у яких записано:
+
Аналогічно, '''DNS- сервер''' може бути ''рекурсивним''  (що уміє виконувати повний пошук) і ''нерекурсивним''  (що не уміє виконувати повний пошук). Деякі програми DNS- серверів, наприклад, BIND, можна конфігурувати так, щоб запити одних клієнтів виконувалися ''рекурсивно'', а запити інших - ''нерекурсивний''.
* яку ІР-адресу має машина з певним іменем;
+
* яке ім'я має машина з визначеною адресою;
+
* що це за комп'ютер і яка операційна система встановлена на ньому;
+
* куди потрібно направляти електронну пошту для користувачів цієї машини;
+
* які псевдоніми є у даної машини.
+
  
Для прикладу розглянемо випадок, коли користувач посилає пошту з машини ''polesye.zhitomir.ua'' користувачу за адресою ''[email protected]'' (знак «@» носить назву ''commercial «at» sign''). При встановленні на машину протоколів TCP/IP системний адміністратор вказує ІР-адресу комп'ютера&nbsp;— найближчого серверу імен. Поштова програма подає цьому найближчому серверу запит: «Куди посилати пошту для ziet.zhitomir.ua» Якщо найближчий сервер не може відповісти, то він, в свою чергу, посилає запит до більш «старшого» серверу. Нарешті, стає зрозумілим, що всю пошту для області ''ziet.zhitomir.ua'' необхідно відправляти на машину ''alpha.ziet.zhitomir.ua'' або ''relay2.lucky.net''. Разом з цим відповіді містять ще адресу цієї машини. Поштова програма зв'язується з цим комп'ютером (використовуючи не ім'я, а адресу) та передає йому пошту. Всі ці переговори та відправка пошти, як правило, відбувається протягом кількох секунд і користувач не помічає цього. Якщо машина ''ziet.zhitomir.ua'' недоступна то тоді пошта на час, в якій неможливо зв'язатися з машиною ''ziet.zhitomir.ua'' (наприклад під час профілактики каналу зв'язку) чекає своєї черги на пересилку на машині ''relay2.lucky.net''.
+
При відповіді на ''нерекурсивний'' запит, а також - при невмінні або забороні виконувати ''рекурсивні'' запити, - DNS- сервер або повертає дані про зону, за яку він '''ответствен''', або повертає адреси серверів, які мають великий об'єм інформації про запрошену зону, чим сервер, що відповідає, найчастіше - адреси кореневих серверів.
  
Це характерна для Internet-програм поведінка. Як правило, поштові програми подають доволі багато запитів службі DNS, і ці питання доволі складні. У більшості випадків у програмах користувачів намагаються дізнатися лише одне&nbsp;— яка ІР-адреса у машини з відповідним іменем. Зрозуміло, що всередині цієї системи імен існує маса нюансів, правил та хитрощів. Більш докладніше з ними можна ознайомитися в описах стандартів Internet або в спеціальних книгах.
+
У разі ''рекурсивного'' запиту '''DNS- сервер''' опитує сервери(в порядку убування рівня зон в імені), поки не знайде відповідь або не виявить, що домен не існує. (На практиці пошук розпочинається з найбільш близьких до шуканого DNS- серверів, якщо інформація про них є в кеші і не застаріла, сервер може не просити інші DNS- сервери.)
 +
 
 +
Розглянемо на прикладі роботу усієї системи.
 +
 
 +
Припустимо, ми набрали в браузері адресу <tt>ru.wikipedia.org</tt>. Браузер запитує у сервера DNS : "яка IP- адреса у <tt>ru.wikipedia.org</tt>"?
 +
Проте, сервер DNS може нічого не знати не лише про запрошене ім'я, але навіть про увесь домен <tt>wikipedia.org</tt>.
 +
В цьому випадку сервер звертається до ''кореневого серверу'' - наприклад, 198.41.0.4. Цей сервер повідомляє - "У мене немає інформації про цю адресу, але я знаю, що 204.74.112.1 є відповідальним за зону <tt>org</tt>". Тоді сервер DNS направляє свій запит до 204.74.112.1, але той відповідає "У мене немає інформації про цей сервер, але я знаю, що 207.142.131.234 є відповідальним за зону <tt>wikipedia.org</tt>". Нарешті, той же запит вирушає до третього DNS- сервера і отримує відповідь - IP- адреса, яка і передається клієнтові - браузеру.
 +
 
 +
В даному випадку при дозволі імені, тобто в процесі пошуку IP по імені:
 +
* браузер відправив відомому йому DNS- серверу ''рекурсивний'' запит - у відповідь на такий тип запиту сервер зобов'язаний повернути "готовий результат", тобто IP- адреса, або порожня відповідь і код помилки NXDOMAIN;
 +
* DNS- сервер, що отримав запит від браузеру, послідовно відправляв ''нерекурсивні'' запити, на які отримував від інших DNS- серверів відповіді, поки не отримав відповідь від сервера, відповідального за запрошену зону;
 +
* інші згадувані DNS- сервери обробляли запити ''нерекурсивний''  (і, швидше за все, не стали б обробляти запити рекурсивно, навіть якщо б така вимога стояла в запиті).
 +
 
 +
Іноді допускається, щоб запрошений сервер передавав ''рекурсивний'' запит "вищестоящому" DNS- серверу і чекав готової відповіді.
 +
 
 +
При ''рекурсивній'' обробці запитів усі відповіді проходять через DNS- сервер, і він дістає можливість ''кешуровати'' їх. Повторний запит на ті ж імена зазвичай не йде далі ''за кеш'' сервера, звернення до інших серверів не відбувається взагалі. Допустимий час зберігання відповідей в ''кеші'' приходить разом з відповідями(поле ''TTL'' '''ресурсного запису''').
 +
 
 +
Рекурсивні запити вимагають більше ресурсів від сервера(і створюють більше трафіку), так що зазвичай приймаються від "відомих" власникові сервера вузлів(наприклад, провайдер надає можливість робити рекурсивні запити тільки своїм клієнтам, в корпоративній мережі рекурсивні запити приймаються тільки з локального сегменту). Нерекурсивні запити зазвичай приймаються від усіх вузлів мережі(і змістовна відповідь дається тільки на запити про зону, яка розміщена на вузлі, на DNS- запит про інші зони зазвичай повертаються адреси інших серверів).
 +
 
 +
=== Зворотний DNS- запит ===
 +
DNS використовується в першу чергу для перетворення символьних імен в IP- адреси, але він також може виконувати зворотний процес. Для цього використовуються вже наявні засоби DNS. Річ у тому, що із записом DNS можуть бути зіставлені різні дані, у тому числі і яке-небудь символьне ім'я. Існує спеціальний домен <tt>in - addr.arpa</tt>, записи в якому використовуються для перетворення IP- адрес в символьні імена. Наприклад, для отримання DNS- імені для адреси <tt>11.22.33.44</tt> можна запросити у DNS- сервера запис <tt>44.33.22.11.in - addr.arpa</tt>, і той поверне відповідне символьне ім'я. Зворотний порядок запису частин IP- адреси пояснюється тим, що в IP- адресах старші біти розташовані на початку, а в символьних DNS- іменах старші(що знаходяться ближче до кореня) частини розташовані у кінці.
 +
 
 +
== Приклад структури доменного імені ==
 +
<center>
 +
[[Файл:Dnsexam.jpg]]
 +
</center>
 +
Першочерговим завданням DNS-сервера є забезпечення трансляції доменних імен в IP-адреси. Для адресації вузлів Інтернету використовуються спеціальні числові «коди» - IP-адреси. Система доменних імен якраз служить для виконання перетворень між символьними і числовими адресами. Традиційна IP-адреса може бути записана за допомогою чотирьох чисел в десятковій системі числення, наприклад: 192.168.175.13 або 194.85.92.93.
 +
 
 +
DNS дозволяє зіставити числову IP-адресу і символьну, наприклад: 194.85.92.93 = test.ru. При цьому символьна адреса в DNS являє собою текстовий рядок, складений за особливими правилами. Найважливіше з цих правил - ієрархія доменів.
 +
 
 +
Система адрес DNS має деревоподібну структуру. Вузли цієї структури називаються доменами. Кожен домен може містити безліч «підлеглих» доменів. Основою даної ієрархічної структури імен т.зв. "Корінь дерева" є точка ("."). Корінь єдиний для всіх доменів. Як правило, при введенні URL, крапка наприкінці адреси не ставиться, проте вона використовується в описах DNS. Цікаво, що про існування кореневого домену зараз пам'ятають лише фахівці. Втім, його можна і вказати. Адресний рядок із зазначенням кореневого домену виглядає, наприклад, так: «site.test.ru.» - тут кореневий домен відділений останньої, крайньої праворуч, крапкою.
 +
 
 +
Нижче кореня лежать домени першого рівня (зони). Їх небагато - COM, NET, ORG, MIL, BIZ, INFO, GOV (є ще кілька) і домени держав, наприклад, RU. Ще нижче знаходяться домени другого рівня, наприклад, test.ru. Ще нижче - третього і т.д. Рівні розділяються крапками.
 +
 
 +
DNS сервер не ізольований. Кожному DNS-СЕРВЕРУ відомі адреси кореневих DNS-серверів. При запиті, DNS-сервер або сам знає відповідь, або знає у кого запитати. Якщо простежити проходження запиту, картина складається досить цікаво. При налаштуванні користувачеві вказується два DNS сервера (первинний і вторинний). Адреси dns серверів вказується провайдером.
 +
 
 +
Користувач відправляє запит первинному DNS серверу. Сервер, у свою чергу, отримавши запит, або відповідає, якщо відповідь йому відома, або відправляє запит на вищого рівня сервер. Якщо вищого рівня сервер не відомий, запит відправляється на кореневий DNS сервер. Так виглядає висхідна (восходящяя) ієрархія. Далі запит починає спускатися вниз від кореневого сервера до сервера першого рівня, той – до СЕРВЕРУ другого рівня і т.д.
 +
 
 +
DNS сервера бувають рекурсивними і нерекурсивними. Рекурсивні сервера завжди повертають користувачеві відповідь. Тобто, вони самостійно опитують інші DNS сервера. Рекурсивні сервера зручно використовувати в локальних мережах. Вони кешують проміжні відповіді, таким чином, при наступних запитах відповіді будуть повертатися набагато швидше. Нерекурсивні сервера повертають користувачеві всі відсилання, так що клієнт повинен самостійно опитувати вказаний сервер. Нерекурсивні сервера зазвичай стоять на верхніх щаблях ієрархії. Вони отримують багато запитів, а для кешування потрібні багато ресурсів. Таким чином, кешування на таких серверах не проводиться.
  
 
== Записи DNS ==
 
== Записи DNS ==
 +
Записи DNS, або ''Ресурсні записи'' (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожен ресурсний запис складається з наступних полів:
 +
 +
* '''''Ім'я''''' (NAME) - доменне ім'я, до якого прив'язана або якому «належить» дана ресурсна запис. Ім'я буває абсолютним (FQDN - Fully Qualified Domain Name) і відносним. Абсолютне ім'я закінчується крапкою. Якщо ж ім'я вказати без крапки в кінці, це ім'я буде вважатися відносним і йому автоматично додається ім'я поточного домену;
 +
* '''''TTL''''' (Time To Live) - допустимий час зберігання даної ресурсної записи в кеші не відповідального DNS-сервера. Даний параметр вказується в секундах;
 +
* '''''Тип''''' (TYPE) ресурсного запису - визначає формат і призначення даного ресурсного запису;
 +
* '''''Клас''''' (CLASS) ресурсного запису; теоретично вважається, що DNS може використовуватися не тільки з TCP / IP, але і з іншими типами мереж, код у полі клас визначає тип мережі;
 +
* '''''Довжина поля даних''''' (RDLEN);
 +
* '''''Поле даних''''' (RDATA), формат і зміст якого залежить від типу запису.
  
 
Найбільш важливі типи DNS-записів:
 
Найбільш важливі типи DNS-записів:
  
*Запис A (address record) або запис адреси пов'язує ім'я хоста з адресою IP. Наприклад, запит A-запису на ім'я referrals.icann.org поверне його IP адреса - 192.0.34.164
+
* '''''Запис A''''' (''address record'') або запис адреси, що зв'язує ім'я хоста з IP адресою. Наприклад, запит A-запису на ім'я '''''referrals.icann.org''''' поверне його IP адресу - '''''192.0.34.164'''''
*Запис AAAA (IPv6 address record) зв'язує ім'я хоста з адресою протоколу IPv6. Наприклад, запит AAAA-запису на ім'я K.ROOT-SERVERS.NET поверне його IPv6 адреса - 2001:7 fd:: 1
+
* '''''Запис AAAA''''' (''IPv6 address record'') зв'язує ім'я хоста з адресою протоколу '''IPv6'''. Наприклад, запит AAAA-запису на ім'я '''''K.ROOT-SERVERS.NET''''' поверне його '''IPv6''' адресу - '''''2001:7 fd:: 1'''''
*Запис CNAME (canonical name record) або канонічна запис імені (псевдонім) використовується для перенаправлення на інше ім'я
+
* '''''Запис CNAME''''' (''canonical name record'') або канонічний запис імені (псевдонім) використовується для перенаправлення на інше ім'я
*Запис MX (mail exchange) або поштову обмінник вказує Поштовий сервер | сервер (и) обміну поштою для цього домену.
+
* '''''Запис MX''''' (''mail exchange'') або поштовий обмінник вказує сервер обміну поштою для даного домену.
*Запис NS (name server) вказує на DNS-сервер для даного домену.
+
* '''''Запис NS''''' (''name server'') вказує на DNS-сервер для даного домену.
*Запис PTR (pointer) або запис покажчика пов'язує IP хоста з його канонічним ім'ям. Запит у домені in-addr.arpa на IP хоста в reverse формі поверне ім'я (FQDN) даного хоста (див. # Зворотній DNS-запит | Зворотній DNS-запит). Наприклад, (на момент написання), для IP адреси 192.0.34.164 : запит запису PTR 164.34.0.192.in-addr.arpa поверне його канонічне ім'я referrals. icann.org. З метою зменшення обсягу небажаної кореспонденції (спаму) багато серверів-одержувачі електронної пошти можуть перевіряти наявність PTR записи для хоста, з якого відбувається відправлення. У цьому випадку PTR запис для IP адреси повинна відповідати імені відправляє поштового сервера, яким він представляється в процесі SMTP сесії.
+
* '''''Запис PTR''''' (''pointer'') або запис покажчика, що зв'язує IP адресу хоста з його канонічним ім'ям. Запит у домені '''''in-addr.arpa''''' на IP хоста в ''reverse'' формі поверне ім'я ('''FQDN''') даного хоста.
*Запис SOA (Start of Authority) або початкова запис зони вказує, на якому сервері зберігається еталонна інформація про даному домені, містить контактну інформацію особи, відповідальної за дану зону, таймінги кешування зонної інформації та взаємодії DNS-серверів.
+
* '''''Запис SOA''''' (''Start of Authority'') або початковий запис зони вказує, на якому сервері зберігається еталонна інформація про даний домен, містить контактну інформацію особи, відповідального за дану зону, таймінги (параметри часу) кешування зонної інформації та взаємодії DNS-серверів.
*Запис SRV (server selection) вказує на сервери для сервісів, використовується, зокрема, для Jabber.
+
* '''''Запис SRV''''' (''server selection'') вказує на сервери для сервісів, використовується, зокрема, для '''''Jabber''''' і '''''Active Directory'''''.
 +
* '''''Запис TXT''''' коментарі або якась інша інформація
 +
* '''''Запис HINFO''''' опис "заліза" комп'ютера
 +
 
 +
'''Базовий формат запису виглядає так:'''
 +
 
 +
[ім'я] [час] [клас] [тип] [дані]
 +
 
 +
== Зарезервовані доменні імена ==
 +
Документ RFC 2606 (Reserved Top Level DNS Names - Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використовувати в якості прикладів (наприклад, в документації), а також для тестування. Крім '''''example.com''''', '''''example.org''''' і '''''example.net''''', до цієї групи також входять '''''test''''', '''''invalid''''' та ін.
 +
 
 +
== Інтернаціональні доменні імена ==
 +
Доменне ім'я може складатися тільки з обмеженого набору '''ASCII''' символів, дозволяючи набрати адресу домену незалежно від мови користувача. '''ICANN''' затвердив засновану на '''''Punycode''''' систему '''IDNA''', перетворюючи будь-який рядок в кодуванні ''Unicode'' в допустимий DNS набір символів.
 +
 
 +
== Програмне забезпечення DNS ==
 +
Сервери імен:
 +
* '''BIND''' (Berkeley Internet Name Domain)
 +
* '''Djbdns''' (Daniel J. Bernstein 's DNS)
 +
* '''MaraDNS'''
 +
* '''NSD''' (Name Server Daemon)
 +
* '''PowerDNS'''
 +
* '''OpenDNS'''
 +
* '''Microsoft DNS Server''' (в серверних версіях операційних систем Windows NT)
 +
* '''MyDNS'''
 +
 
 +
== Інформація про домен ==
 +
Багато доменів верхнього рівня підтримують сервіс '''''whois''''', який дозволяє дізнатися, кому делеговано домен і іншу технічну інформацію.
 +
 
 +
== Реєстрація домену ==
 +
Реєстрація домену - процедура отримання доменного імені. Полягає у створенні записів, що вказують на адміністратора домену, в базі даних DNS. Порядок реєстрації та вимоги залежать від обраної доменної зони. Реєстрація домену може бути виконана як організацією-реєстратором, так і приватною особою, якщо це дозволяють правила обраної доменної зони.
 +
 
 +
[[Служба DNS]]
 +
 
 +
== [[Сторінка питань з DNS/DHCP]] ==
  
[[TCP/IP]]
 
 
[[category:Комп'ютерні мережі]]
 
[[category:Комп'ютерні мережі]]

Поточна версія на 17:59, 16 січня 2014

DomainNameSystem.jpg

Назва: Domain Name Server
Рівень (по моделі OSI): Прикладний
Сімейство: TCP/IP
Порт/ID: 53/TCP, 53/UDP
Призначення протоколу: Розширення доменних імен
Специфікація: RFC 1034 , RFC 1035 / STD 13
Основні реалізації (клієнти): Вбудована у всі мережеві ОС
Основні реалізації (сервери): BIND, PowerDNS або Microsoft DNS Server

DNS (англ. Domain Name System - система доменних імен) - це розподілена комп'ютерна система для отримання інформації про домени. Найчастіше використовується для отримання IP-адреси по імені хоста (комп'ютера або пристрою), отримання інформації про маршрутизацію пошти , обслуговуваних вузлах для протоколів у домені (SRV-запис).

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

Основою DNS є представлення про ієрархічну структуру доменного імені та зонах.

  • Кожен сервер, відповідаючи за ім'я, може делегувати відповідальність за подальшу частину домену іншому серверу (з адміністративної точки зору - іншій організації або людині), що дозволяє покласти відповідальність за актуальність інформації на сервери різноманітних організацій (людей), відповідаючи тільки за «свою» частину доменного імені.
  • Зона (zone) це окремо адмініструються частина дерева DNS. Наприклад, домен другого рівня noao.edu це окрема зона. Багато доменів другого рівня поділені на менші зони. Наприклад, університет може поділити свою зону на підзони по факультетах, а компанія може поділити себе на зони за принципом поділу на філії або відділи.

Ключові характеристики DNS

DNS володіє наступними характеристиками:

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

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

DNS була розроблена Полом Мокапетрісом у 1983 році; оригінальне опис механізмів роботи міститься в стандартах RFC 882 та RFC 883. У 1987 публікація RFC 1034 і RFC 1035 змінила специфікацію DNS і скасувала RFC 882 та RFC 883 як застарілі.

Додаткові можливості

  • Підтримка динамічних оновлень
  • Захист даних (DNSSEC) і транзакцій (TSIG)
  • Підтримка різноманітних типів інформації (SRV-записи)

Термінологія і принципи роботи

Основна область застосування DNS це перетворення імені хоста (Під "хостом" мається на увазі комп'ютер або сервер, підключеної до локальної мережі, або інтернету.) в IP-адресу та надання даних про маршрутизації пошти.

Принцип роботи. Коли користувач запускає веб-браузер в вводить назву домену сайту, його ПК відправляє запит до DNS-сервера інтернет-провайдера для отримання IP-адреси, на якому знаходиться домен (1). Якщо DNS-сервери провайдера не виявляють у своєму кеші інформації про запитуваній сайт, то відправляють запит на кореневі DNS-сервери (2).

Кореневий DNS-сервер шукає в своїй базі даних інформацію про сервери імен хостинг-провайдера, на яких присутній цей сайт. Далі, він повідомляє з кешируючого DNS-сервера провайдера (3).

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

І вже після цього браузер, отримавши IP-адреса запитуваного сайту, переходить на сам сайт (7 і 8).

WorkDNS.jpg

Ключовими поняттями DNS є:

  • Домен (англ. domain - область) - вузол в дереві імен, разом з усіма підлеглими йому вузлами (якщо такі є), тобто іменована гілка або піддерево в дереві імен. Структура доменного імені зображає порядок проходження вузлів в ієрархії; доменне ім'я читається зліва направо від молодших доменів до доменів вищого рівня (в порядку підвищення значимості), кореневим доменом всієї системи є крапка ('.'), нижче йдуть домени першого рівня (географічні або тематичні ), потім - домени другого рівня, третього і т. д. (наприклад, для адреси ua.wikipedia.org домен першого рівня - org, другого wikipedia, третього ua). На практиці крапку в кінці імені часто опускають, але вона буває важлива у випадках поділу між відносними доменами і FQDN (англ. Fully Qualifed Domain Name, повністю визначене ім'я домену).
  • Піддомен (англ. subdomain) - підлеглий домен. (Наприклад, wikipedia.org - піддомен домену org, а ua.wikipedia.org - домену wikipedia.org). Теоретично такий розподіл може досягати глибини 127 рівнів, а кожна мітка може містити до 63 символів, поки загальна довжина разом з точками не досягне 254 символів. Але на практиці реєстратори доменних імен використовують більш суворі обмеження. Наприклад, якщо у вас є домен виду mydomain.ru, ви можете створити для нього різні піддомени виду mysite1.mydomain.ru, mysite2.mydomain.ru і т. д.
  • Ресурсний запис - одиниця зберігання і передачі інформації в DNS. Кожний ресурсний запис має ім'я (тобто прив'язаний до певного доменного імені, вузлу в дереві імен), тип і поле даних, формат і зміст якого залежить від типу.
  • Зона - частина дерева доменних імен (включаючи ресурсні записи), що розміщується як єдине ціле на деякому сервері доменних імен (DNS-сервер), а частіше - одночасно на декількох серверах. Метою виділення частини дерева в окрему зону є передача відповідальності за відповідний Домен іншій особі або організації, так зване Делегування. Як зв'язкова частина дерева, зона всередині теж являє собою дерево. Якщо розглядати простір імен DNS як структуру із зон, а не окремих вузлів / імен, теж виходить дерево; виправдано казати про батьківські і дочірні зони, про старших і підлеглих. На практиці, більшість зон 0-го і 1-го рівня ('.', ru, com, ...) складаються з єдиного вузла, якому безпосередньо підпорядковуються дочірні зони. У великих корпоративних доменах (2-го і більше рівнів) іноді зустрічається утворення додаткових підлеглих рівнів без виділення їх у дочірні зони.
  • Делегування - операція передачі відповідальності за частину дерева доменних імен іншій особі або організації. За рахунок делегування в DNS забезпечується розподільність адміністрування та зберігання. Технічно делегування виражається у виділенні цієї частини дерева в окрему зону, та розміщення цієї зони на DNS-сервер, керованому цією особою чи організацією. При цьому в батьківську зону включаються «склеюючи» ресурсні записи (NS і А), що містять покажчики на DNS-сервера дочірньої зони, а вся інша інформація, що відноситься до дочірньої зоні, зберігається вже на DNS-серверах дочірньої зони.
  • DNS-сервер - спеціалізоване ПО для обслуговування DNS, а також комп'ютер, на якому це ПЗ виконується. DNS-сервер може бути відповідальним за певні зони і / або може перенаправляти запити серверам, що знаходяться вище за ієрархією.
  • DNS-клієнт - спеціалізована бібліотека (або програма) для роботи з DNS. У ряді випадків DNS-сервер виступає в ролі DNS-клієнта.
  • Авторитетність (англ. authoritative) - ознака розміщення зони на DNS-сервері. Відповіді DNS-сервера можуть бути двох типів: авторитетні (коли сервер заявляє, що сам відповідає за зону) і неавторитетний (англ. Non-authoritative), коли сервер обробляє запит, і повертає відповідь інших серверів. У деяких випадках замість передачі запиту далі DNS-сервер може повернути вже відоме йому (за запитами раніше) значення (режим кешування).
  • DNS-запит (англ. DNS query) - запит від клієнта (або сервера) серверу. Запит може бути рекурсивним або нерекурсивним.

Система DNS містить ієрархію DNS-серверів, відповідну до ієрархії зон. Кожна зона підтримується як мінімум одним авторитетним сервером DNS (від англ. Authoritative - авторитетний), на якому розташована інформація про домен.

Ім'я та IP-адреса не тотожні - одина IP-адреса може мати безліч імен, що дозволяє підтримувати на одному комп'ютері безліч веб-сайтів (це називається віртуальний хостинг). Зворотне теж справедливо - одному імені можна порівнювати безліч IP-адрес: це дозволяє створювати балансування навантаження.

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

Рекурсія

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

DNS- запит може бути рекурсивним - що вимагає повного пошуку, - і нерекурсивним (чи ітеративним) - що не вимагає повного пошуку.

Аналогічно, DNS- сервер може бути рекурсивним (що уміє виконувати повний пошук) і нерекурсивним (що не уміє виконувати повний пошук). Деякі програми DNS- серверів, наприклад, BIND, можна конфігурувати так, щоб запити одних клієнтів виконувалися рекурсивно, а запити інших - нерекурсивний.

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

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

Розглянемо на прикладі роботу усієї системи.

Припустимо, ми набрали в браузері адресу ru.wikipedia.org. Браузер запитує у сервера DNS : "яка IP- адреса у ru.wikipedia.org"? Проте, сервер DNS може нічого не знати не лише про запрошене ім'я, але навіть про увесь домен wikipedia.org. В цьому випадку сервер звертається до кореневого серверу - наприклад, 198.41.0.4. Цей сервер повідомляє - "У мене немає інформації про цю адресу, але я знаю, що 204.74.112.1 є відповідальним за зону org". Тоді сервер DNS направляє свій запит до 204.74.112.1, але той відповідає "У мене немає інформації про цей сервер, але я знаю, що 207.142.131.234 є відповідальним за зону wikipedia.org". Нарешті, той же запит вирушає до третього DNS- сервера і отримує відповідь - IP- адреса, яка і передається клієнтові - браузеру.

В даному випадку при дозволі імені, тобто в процесі пошуку IP по імені:

  • браузер відправив відомому йому DNS- серверу рекурсивний запит - у відповідь на такий тип запиту сервер зобов'язаний повернути "готовий результат", тобто IP- адреса, або порожня відповідь і код помилки NXDOMAIN;
  • DNS- сервер, що отримав запит від браузеру, послідовно відправляв нерекурсивні запити, на які отримував від інших DNS- серверів відповіді, поки не отримав відповідь від сервера, відповідального за запрошену зону;
  • інші згадувані DNS- сервери обробляли запити нерекурсивний (і, швидше за все, не стали б обробляти запити рекурсивно, навіть якщо б така вимога стояла в запиті).

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

При рекурсивній обробці запитів усі відповіді проходять через DNS- сервер, і він дістає можливість кешуровати їх. Повторний запит на ті ж імена зазвичай не йде далі за кеш сервера, звернення до інших серверів не відбувається взагалі. Допустимий час зберігання відповідей в кеші приходить разом з відповідями(поле TTL ресурсного запису).

Рекурсивні запити вимагають більше ресурсів від сервера(і створюють більше трафіку), так що зазвичай приймаються від "відомих" власникові сервера вузлів(наприклад, провайдер надає можливість робити рекурсивні запити тільки своїм клієнтам, в корпоративній мережі рекурсивні запити приймаються тільки з локального сегменту). Нерекурсивні запити зазвичай приймаються від усіх вузлів мережі(і змістовна відповідь дається тільки на запити про зону, яка розміщена на вузлі, на DNS- запит про інші зони зазвичай повертаються адреси інших серверів).

Зворотний DNS- запит

DNS використовується в першу чергу для перетворення символьних імен в IP- адреси, але він також може виконувати зворотний процес. Для цього використовуються вже наявні засоби DNS. Річ у тому, що із записом DNS можуть бути зіставлені різні дані, у тому числі і яке-небудь символьне ім'я. Існує спеціальний домен in - addr.arpa, записи в якому використовуються для перетворення IP- адрес в символьні імена. Наприклад, для отримання DNS- імені для адреси 11.22.33.44 можна запросити у DNS- сервера запис 44.33.22.11.in - addr.arpa, і той поверне відповідне символьне ім'я. Зворотний порядок запису частин IP- адреси пояснюється тим, що в IP- адресах старші біти розташовані на початку, а в символьних DNS- іменах старші(що знаходяться ближче до кореня) частини розташовані у кінці.

Приклад структури доменного імені

Dnsexam.jpg

Першочерговим завданням DNS-сервера є забезпечення трансляції доменних імен в IP-адреси. Для адресації вузлів Інтернету використовуються спеціальні числові «коди» - IP-адреси. Система доменних імен якраз служить для виконання перетворень між символьними і числовими адресами. Традиційна IP-адреса може бути записана за допомогою чотирьох чисел в десятковій системі числення, наприклад: 192.168.175.13 або 194.85.92.93.

DNS дозволяє зіставити числову IP-адресу і символьну, наприклад: 194.85.92.93 = test.ru. При цьому символьна адреса в DNS являє собою текстовий рядок, складений за особливими правилами. Найважливіше з цих правил - ієрархія доменів.

Система адрес DNS має деревоподібну структуру. Вузли цієї структури називаються доменами. Кожен домен може містити безліч «підлеглих» доменів. Основою даної ієрархічної структури імен т.зв. "Корінь дерева" є точка ("."). Корінь єдиний для всіх доменів. Як правило, при введенні URL, крапка наприкінці адреси не ставиться, проте вона використовується в описах DNS. Цікаво, що про існування кореневого домену зараз пам'ятають лише фахівці. Втім, його можна і вказати. Адресний рядок із зазначенням кореневого домену виглядає, наприклад, так: «site.test.ru.» - тут кореневий домен відділений останньої, крайньої праворуч, крапкою.

Нижче кореня лежать домени першого рівня (зони). Їх небагато - COM, NET, ORG, MIL, BIZ, INFO, GOV (є ще кілька) і домени держав, наприклад, RU. Ще нижче знаходяться домени другого рівня, наприклад, test.ru. Ще нижче - третього і т.д. Рівні розділяються крапками.

DNS сервер не ізольований. Кожному DNS-СЕРВЕРУ відомі адреси кореневих DNS-серверів. При запиті, DNS-сервер або сам знає відповідь, або знає у кого запитати. Якщо простежити проходження запиту, картина складається досить цікаво. При налаштуванні користувачеві вказується два DNS сервера (первинний і вторинний). Адреси dns серверів вказується провайдером.

Користувач відправляє запит первинному DNS серверу. Сервер, у свою чергу, отримавши запит, або відповідає, якщо відповідь йому відома, або відправляє запит на вищого рівня сервер. Якщо вищого рівня сервер не відомий, запит відправляється на кореневий DNS сервер. Так виглядає висхідна (восходящяя) ієрархія. Далі запит починає спускатися вниз від кореневого сервера до сервера першого рівня, той – до СЕРВЕРУ другого рівня і т.д.

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

Записи DNS

Записи DNS, або Ресурсні записи (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожен ресурсний запис складається з наступних полів:

  • Ім'я (NAME) - доменне ім'я, до якого прив'язана або якому «належить» дана ресурсна запис. Ім'я буває абсолютним (FQDN - Fully Qualified Domain Name) і відносним. Абсолютне ім'я закінчується крапкою. Якщо ж ім'я вказати без крапки в кінці, це ім'я буде вважатися відносним і йому автоматично додається ім'я поточного домену;
  • TTL (Time To Live) - допустимий час зберігання даної ресурсної записи в кеші не відповідального DNS-сервера. Даний параметр вказується в секундах;
  • Тип (TYPE) ресурсного запису - визначає формат і призначення даного ресурсного запису;
  • Клас (CLASS) ресурсного запису; теоретично вважається, що DNS може використовуватися не тільки з TCP / IP, але і з іншими типами мереж, код у полі клас визначає тип мережі;
  • Довжина поля даних (RDLEN);
  • Поле даних (RDATA), формат і зміст якого залежить від типу запису.

Найбільш важливі типи DNS-записів:

  • Запис A (address record) або запис адреси, що зв'язує ім'я хоста з IP адресою. Наприклад, запит A-запису на ім'я referrals.icann.org поверне його IP адресу - 192.0.34.164
  • Запис AAAA (IPv6 address record) зв'язує ім'я хоста з адресою протоколу IPv6. Наприклад, запит AAAA-запису на ім'я K.ROOT-SERVERS.NET поверне його IPv6 адресу - 2001:7 fd:: 1
  • Запис CNAME (canonical name record) або канонічний запис імені (псевдонім) використовується для перенаправлення на інше ім'я
  • Запис MX (mail exchange) або поштовий обмінник вказує сервер обміну поштою для даного домену.
  • Запис NS (name server) вказує на DNS-сервер для даного домену.
  • Запис PTR (pointer) або запис покажчика, що зв'язує IP адресу хоста з його канонічним ім'ям. Запит у домені in-addr.arpa на IP хоста в reverse формі поверне ім'я (FQDN) даного хоста.
  • Запис SOA (Start of Authority) або початковий запис зони вказує, на якому сервері зберігається еталонна інформація про даний домен, містить контактну інформацію особи, відповідального за дану зону, таймінги (параметри часу) кешування зонної інформації та взаємодії DNS-серверів.
  • Запис SRV (server selection) вказує на сервери для сервісів, використовується, зокрема, для Jabber і Active Directory.
  • Запис TXT коментарі або якась інша інформація
  • Запис HINFO опис "заліза" комп'ютера

Базовий формат запису виглядає так:

[ім'я] [час] [клас] [тип] [дані]

Зарезервовані доменні імена

Документ RFC 2606 (Reserved Top Level DNS Names - Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використовувати в якості прикладів (наприклад, в документації), а також для тестування. Крім example.com, example.org і example.net, до цієї групи також входять test, invalid та ін.

Інтернаціональні доменні імена

Доменне ім'я може складатися тільки з обмеженого набору ASCII символів, дозволяючи набрати адресу домену незалежно від мови користувача. ICANN затвердив засновану на Punycode систему IDNA, перетворюючи будь-який рядок в кодуванні Unicode в допустимий DNS набір символів.

Програмне забезпечення DNS

Сервери імен:

  • BIND (Berkeley Internet Name Domain)
  • Djbdns (Daniel J. Bernstein 's DNS)
  • MaraDNS
  • NSD (Name Server Daemon)
  • PowerDNS
  • OpenDNS
  • Microsoft DNS Server (в серверних версіях операційних систем Windows NT)
  • MyDNS

Інформація про домен

Багато доменів верхнього рівня підтримують сервіс whois, який дозволяє дізнатися, кому делеговано домен і іншу технічну інформацію.

Реєстрація домену

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

Служба DNS

Сторінка питань з DNS/DHCP