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

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук
 
(не показані 39 проміжних версій 3 учасників)
Рядок 1: Рядок 1:
 +
<center>
 +
[[Файл:DomainNameSystem.jpg]]
 +
</center>
 +
 +
{|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''' (англ. ''Domain Name System'' - система доменних імен) - це розподілена комп'ютерна система для отримання інформації про домени. Найчастіше використовується для отримання IP-адреси по імені хоста (комп'ютера або пристрою), отримання інформації про маршрутизацію пошти , обслуговуваних вузлах для протоколів у домені (SRV-запис).
 
'''DNS''' (англ. ''Domain Name System'' - система доменних імен) - це розподілена комп'ютерна система для отримання інформації про домени. Найчастіше використовується для отримання IP-адреси по імені хоста (комп'ютера або пристрою), отримання інформації про маршрутизацію пошти , обслуговуваних вузлах для протоколів у домені (SRV-запис).
  
Розподілена база даних DNS підтримуеться за допомогою ієрархії DNS-серверів, взаемодіючих за певним протоколом.
+
Розподілена база даних DNS підтримується за допомогою ієрархії DNS-серверів, взаємодіючи за певним протоколом.
  
Основою DNS є представлення про ієрархічну структуру доменного імені та зонах. Кожен сервер, водповідаючий за ім'я, може делегувати відповідальність за подальшу частину домену іншому серверу (з адміністративної точки зору - іншій організації або людині), що дозволяє покласти відповідальність за актуальність інформації на сервери різноманітних організацій (людей), відповідаючих тільки за «свою» частину доменного імені.
+
Основою DNS є представлення про ієрархічну структуру доменного імені та зонах.  
 +
*Кожен сервер, відповідаючи за ім'я, може делегувати відповідальність за подальшу частину домену іншому серверу (з адміністративної точки зору - іншій організації або людині), що дозволяє покласти відповідальність за актуальність інформації на сервери різноманітних організацій (людей), відповідаючи тільки за «свою» частину доменного імені.
  
== Ключові характеристики DNS ==
+
*Зона (zone) це окремо адмініструються частина дерева DNS. Наприклад, домен другого рівня '''''noao.edu''''' це окрема зона. Багато доменів другого рівня поділені на менші зони. Наприклад, університет може поділити свою зону на підзони по факультетах, а компанія може поділити себе на зони за принципом поділу на філії або відділи.
  
 +
== Ключові характеристики DNS ==
 
DNS володіє наступними характеристиками:
 
DNS володіє наступними характеристиками:
* ''Розподільність адміністрування''. Відповідальність за різні частини ієрархічної структури несуть різні люди та організації.
+
* '''''Розподільність адміністрування'''''. Відповідальність за різні частини ієрархічної структури несуть різні люди та організації.
* ''розподільність збереження інформації''. Кожен вузол мережі в обов'язковому порядку повинен зберігати тільки ті данні, які належать до його зони відповідальності і (можливо) адреси кінцевих DNS-серверів.
+
* '''''Розподільність збереження інформації'''''. Кожен вузол мережі в обов'язковому порядку повинен зберігати тільки ті данні, які належать до його зону відповідальності і (можливо) адреси кінцевих DNS-серверів.
 
+
* '''''Кеширування інформації'''''. Вузол може зберігати деяку кількість даних не із власної зони відповідальності для зменшення навантаження на мережу.
 +
* '''''Ієрархічна структура''''', у якій усі вузли об'єднані у дерево, а кожен вузол може або самостійно визначати роботу нижчих за ієрархію вузлів, або делегувати ( передавати) їх іншим вузлам.
 +
* '''''Резервування'''''. За збереження та обслуговування своїх вузлів (зон) відповідають (зазвичай) декілька серверів, розподілених як фізично, так і логічно, що забезпечує зберігання даних та продовження роботи навіть у разі виходу з ладу одного з вузлів.
  
== Принцип роботи DNS-серверу ==
+
DNS важлива для роботи мережі Інтернет, так як для з'єднання з вузлом необхідна інформація про його IP-адресу, а для людей легше запам'ятати символьні (зазвичай змістовні) адреси, ніж послідовність цифр IP-адрес. У деяких випадках це дозволяє використовувати віртуальні сервери, наприклад, HTTP-сервери, розрізняючи їх по імені запиту. Спочатку перетворення між доменними та IP-адресами відбувалося з використанням спеціального текстового файлу '''hosts''', який складався централізовано та автоматично відправлявся на кожну з машин у своїй локальній мережі. З ростом Мережі виникла необхідність в ефективному, автоматизованому механізмі, яким і стала DNS.
  
Если посмотреть большинство более-менее популярных статей об устройстве Интернета, то про DNS там чаще всего будет сказано что-то типа "DNS-сервер обеспечивает трансляцию имен сайтов в IP адреса". В принципе, это действительно является его основной задачей, и для большинства пользователей (и даже компьютерщиков) этих знаний вполне достаточно. Но если вдруг вам придется отлаживать сеть, которой провайдер выделил какой-то блок "честных" адресов, или поднимать в локальной сети свой DNS-сервер, то очень быстро всплывут всякие страшные слова: "зона", "трансфер", "форвардер", "in-addr.arpa" и другие... Поэтому в этой заметке мы попробуем чуть более подробно поговорить о работе DNS.
+
DNS була розроблена Полом Мокапетрісом у 1983 році; оригінальне опис механізмів роботи міститься в стандартах RFC 882 та RFC 883. У 1987 публікація RFC 1034 і RFC 1035 змінила специфікацію DNS і скасувала RFC 882 та RFC 883 як застарілі.
  
Очень приблизительно можно сказать, что у каждого компьютера в Интернете есть два основных идентификатора: доменное имя (например, www.listsoft.ru) и IP-адрес (например, 127.0.0.1). Приблизительность заключается в том, что, во-первых, IP-адресов у компьютера может быть несколько (мало того, что у каждого интерфейса свой адрес, так еще и несколько адресов могут "висеть" на одном интерфейсе); во-вторых, имен тоже может быть несколько, причем они могут связываться как с одним, так и с несколькими IP-адресами; в-третьих, у компьютера может и не быть доменного имени... Словом, ясно, что картина уже начинает запутываться.
+
== Додаткові можливості ==
 +
* Підтримка динамічних оновлень
 +
* Захист даних ('''DNSSEC''') і транзакцій ('''TSIG''')
 +
* Підтримка різноманітних типів інформації (SRV-записи)
  
Как было сказано выше, основной задачей DNS-сервера является трансляция доменных имен в IP адреса и обратно. На заре становления Интернета (когда он еще был ARPANET'ом) это решалось ведением длинных списков, включающих все компьютеры сети, причем копия такого списка должна была присутствовать на каждом компьютере. Понятно, что с ростом сети эта технология перестала удовлетворять кого бы то ни было — ведь эти файлы надо было еще и синхронизировать, не говоря уж об их размере... Некоторые "пережитки" этого метода можно обнаружить и сейчас: существует файл HOSTS (и в UNIX, и в Windows), в котором можно прописывать адреса серверов, с которыми вы регулярно работаете (кстати, именно его использование лежит в основе многих "ускорителей Интернета" — такие программы просто записывают адреса серверов, к которым вы обращаетесь, в файл HOSTS и при следующем обращении берут данные из него, не тратя время на запрос к DNS-серверу).
+
== Термінологія і принципи роботи ==
 +
Основна область застосування DNS це перетворення імені хоста (Під "хостом" мається на увазі комп'ютер або сервер, підключеної до локальної мережі, або інтернету.) в IP-адресу та надання даних про маршрутизації пошти.  
  
На смену "однофайловой" схеме пришел DNS — иерархическая структура имен. Существует "корень дерева" с именем "." (точка). Так как корень един для всех доменов, то точка в конце имени обычно не ставится (но она используется в описаниях DNS — тут надо быть очень внимательным!). Ниже корня лежат домены первого уровня. Их немного — com, net, edu, org, mil, int, biz, info, gov (есть еще несколько) и домены государств, например, ru. Еще ниже находятся домены второго уровня, например, listsoft.ru. Еще ниже — третьего и т.д.  
+
Принцип роботи.
 +
Коли користувач запускає веб-браузер в вводить назву домену сайту, його ПК відправляє запит до DNS-сервера інтернет-провайдера для отримання IP-адреси, на якому знаходиться домен (1).
 +
Якщо DNS-сервери провайдера  не виявляють у своєму кеші інформації про запитуваній сайт, то відправляють запит на кореневі DNS-сервери (2).
  
Иерархичность DNS-серверов — штука довольно интересная, если проследить прохождение запроса. При установке (точнее, при настройке) клиенту указывается как минимум один DNS-сервер (как правило, их два) — его адрес выдается провайдером. Клиент посылает запрос этому серверу. Сервер, получив запрос, либо отвечает (если ответ ему известен), либо пересылает запрос на "вышестоящий" сервер (если он известен) или на корневой (каждому DNS-серверу известны адреса корневых DNS-серверов). Так выглядит "восходящая иерархия". Затем запрос начинает спускаться вниз — корневой сервер пересылает запрос серверу первого уровня, тот — серверу второго уровня и т.д. Таким образом, каждый DNS-сервер работает как хороший компьютерщик: он всегда либо знает ответ, либо знает, у кого спросить...
+
Кореневий DNS-сервер шукає в своїй базі даних інформацію про сервери імен хостинг-провайдера, на яких присутній цей сайт. Далі, він повідомляє з кешируючого DNS-сервера провайдера (3).
  
Помимо "вертикальных связей", у серверов есть еще и "горизонтальные" отношения — "первичный — вторичный". Действительно, если предположить, что сервер, обслуживающий какой-то домен и работающий "без страховки" вдруг перестанет быть доступным, то все машины, расположенные в этом домене, окажутся недоступны! Именно поэтому при регистрации домена второго уровня выдвигается требование указать минимум два сервера DNS, которые будут этот домен обслуживать.  
+
Після того, як кешуючий DNS-сервер провайдера отримує інформацію про сервери імен провайдера він опитує будь-який з них (4) і, у разі отримання позитивного результату отримання IP-адреси (5), поміщає в кеш (Кешування використовується для того, щоб знизити як навантаження на інтернет-канали, так і для прискорення отримання результату запиту).
 +
Після цього DNS-сервер провайдера передає IP-адреса браузеру користувача, який здійснив запит сайту (6).
  
DNS-сервера бывают рекурсивные и нерекурсивные. Первые всегда возвращают клиенту ответ — они самостоятельно отслеживают отсылки к другим DNS-серверам и опрашивают их. Нерекурсивные сервера возвращают клиенту эти отсылки, так что клиент должен самостоятельно опрашивать указанный сервер. Рекурсивные сервера удобно использовать на низких уровнях, в частности, в локальных сетях. Дело в том, что они кэшируют все промежуточные ответы, и при последующих запросах ответы будут возвращаться намного быстрее. Нерекурсивные сервера обычно стоят на верхних ступенях иерархии — поскольку они получают очень много запросов, то для кэширования ответов никаких ресурсов не хватит.  
+
І вже після цього браузер, отримавши IP-адреса запитуваного сайту, переходить на сам сайт (7 і 8).
 +
<center>
 +
[[Файл:workDNS.jpg]]
 +
</center>
  
Полезным свойством DNS является умение использовать "пересыльщиков" (forwarders). "Честный" DNS-сервер самостоятельно опрашивает другие сервера и находит нужный ответ, но если ваша сеть подключена к Интернету по медленной (например, dial-up) линии, то этот процесс может занимать довольно много времени. Вместо этого можно перенаправлять все запросы, скажем, на сервер провайдера, а затем принимать его ответ. Использование "пересыльщиков" может оказаться интересным и для больших компаний с несколькими сетями: в каждой сети можно поставить относительно слабый DNS-сервер, указав в качестве "пересыльщика" более мощную машину, подключенную по быстрой линии. При этом все ответы будут кэшироваться на этом мощном сервере, что ускорит разрешение имен для целой сети.
+
'''Ключовими поняттями 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 містить ієрархію DNS-серверів, відповідну до ієрархії зон. Кожна зона підтримується як мінімум одним авторитетним сервером DNS (від англ. ''Authoritative'' - авторитетний), на якому розташована інформація про домен.
  
Элементы базы DNS часто называют RR (сокращение от Resource Record). Базовый формат записи выглядит так:
+
Ім'я та IP-адреса не тотожні - одина IP-адреса може мати безліч імен, що дозволяє підтримувати на одному комп'ютері безліч веб-сайтів (це називається віртуальний хостинг). Зворотне теж справедливо - одному імені можна порівнювати безліч IP-адрес: це дозволяє створювати балансування навантаження.
  
[имя] [время] [класс] тип данные
+
Для підвищення стійкості системи використовується безліч серверів, що містять ідентичну інформацію, а в протоколі є засоби, що дозволяють підтримувати синхронність інформації, розташованої на різних серверах. Існує 13 кореневих серверів, їх адреси практично не змінюються.
  
Имя может быть относительным или абсолютным (FQDN — Fully Qualified Domain Name). Если имя относительное (не заканчивается точкой — помните про корневой домен?), то к нему автоматически добавляется имя текущего домена. Например, если в домене listsoft.ru я опишу имя «www», то полное имя будет интерпретироваться как "www.listsoft.ru." Если же это имя указать как "www.listsoft.ru" (без последней точки), то оно будет считаться относительным и будет интерпретировано как "www.listsoft.ru.listsoft.ru."
+
=== [[Рекурсія]] ===
  
Время задает интервал времени в секундах, в течение которого данные могут сохраняться в кэше сервера.  
+
Терміном '''Рекурсія''' в DNS означають алгоритм поведінки '''DNS- сервера''', при якому сервер виконує від імені клієнта повний пошук потрібної інформації в усій системі DNS, при необхідності звертаючись до іншим '''DNS- серверам'''.
  
класс определяет класс сети. Практически всегда это будет IN, обозначающее INternet.
+
'''DNS- запит''' може бути ''рекурсивним'' - що вимагає повного пошуку, - і ''нерекурсивним''  (чи ''ітеративним'') - що не вимагає повного пошуку.
  
Тип может быть одним из следующих:
+
Аналогічно, '''DNS- сервер''' може бути ''рекурсивним''  (що уміє виконувати повний пошук) і ''нерекурсивним''  (що не уміє виконувати повний пошук). Деякі програми DNS- серверів, наприклад, BIND, можна конфігурувати так, щоб запити одних клієнтів виконувалися ''рекурсивно'', а запити інших - ''нерекурсивний''.
SOA — определяет DNS зону
+
NS — сервер имен для зоны
+
A — преобразование имени в IP-адрес
+
PTR — преобразование IP-адреса в имя
+
MX — почтовая станция
+
CNAME — имена машины
+
HINFO — описание "железа" компьютера
+
TXT — комментарии или какая-то другая информация
+
  
Есть также некоторые другие типы, но они намного менее распространены.
+
При відповіді на ''нерекурсивний'' запит, а також - при невмінні або забороні виконувати ''рекурсивні'' запити, - DNS- сервер або повертає дані про зону, за яку він '''ответствен''', або повертає адреси серверів, які мають великий об'єм інформації про запрошену зону, чим сервер, що відповідає, найчастіше - адреси кореневих серверів.
  
В записях можно использовать символы # и ; для комментариев, @ для обозначения текущего домена, () — скобки — для написания данных на нескольких строках. Кроме того, можно использовать метасимвол * в имени. Порядок записей не имеет значения за одним исключением: запись SOA должна идти первой. Дальнейшие записи считаются относящимися к той же зоне, пока не встретится новая запись SOA. Как правило, после записи зоны указывают записи DNS-серверов, а остальные записи располагают по алфавиту, но это не обязательно.  
+
У разі ''рекурсивного'' запиту '''DNS- сервер''' опитує сервери(в порядку убування рівня зон в імені), поки не знайде відповідь або не виявить, що домен не існує. (На практиці пошук розпочинається з найбільш близьких до шуканого DNS- серверів, якщо інформація про них є в кеші і не застаріла, сервер може не просити інші DNS- сервери.)
  
Теперь попробуем рассмотреть записи. Первой описываем зону:
+
Розглянемо на прикладі роботу усієї системи.
mycompany.ru. IN SOA ns.mycompany.ru. admin.mycompany.ru. (1001 ; serial
+
21600 ; Refresh — 6 часов
+
1800 ; Retry — 30 мин
+
1209600 ; Expire — 2 недели
+
432000) ; Minimum — 5 дней
+
  
Сначала идет имя домена: mycompany.ru. (обратите внимание на точку в конце имени). Вместо имени можно было (и чаще всего так и делают) поставить знак @.
+
Припустимо, ми набрали в браузері адресу <tt>ru.wikipedia.org</tt>. Браузер запитує у сервера DNS : "яка IP- адреса у <tt>ru.wikipedia.org</tt>"?
ns.mycompany.ru. — основной сервер имен
+
Проте, сервер DNS може нічого не знати не лише про запрошене ім'я, але навіть про увесь домен <tt>wikipedia.org</tt>.
admin.mycompany.ru. — почтовый адрес администратора в формате имя(точка)машина
+
В цьому випадку сервер звертається до ''кореневого серверу'' - наприклад, 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- адреса, яка і передається клієнтові - браузеру.
  
затем в круглых скобках идут поля, необходимые для правильного "восприятия" вашей зоны другими серверами. Первое число — serial — является "версией" файла зоны. При внесении изменений это число надо увеличить — если вторичный сервер увидит, что его версия зоны меньше, чем у первичного сервера, то он перечитает данные. Типичной ошибкой является обновление зоны без обновления этого числа. Очень удобно в качестве serial использовать текущую дату, например, 2003040401 — 4 апреля 2003 года, первое обновление.
+
В даному випадку при дозволі імені, тобто в процесі пошуку IP по імені:
Refresh говорит вторичным серверам, как часто они должны проверять значение serial.
+
* браузер відправив відомому йому DNS- серверу ''рекурсивний'' запит - у відповідь на такий тип запиту сервер зобов'язаний повернути "готовий результат", тобто IP- адреса, або порожня відповідь і код помилки NXDOMAIN;
 +
* DNS- сервер, що отримав запит від браузеру, послідовно відправляв ''нерекурсивні'' запити, на які отримував від інших DNS- серверів відповіді, поки не отримав відповідь від сервера, відповідального за запрошену зону;
 +
* інші згадувані DNS- сервери обробляли запити ''нерекурсивний''  (і, швидше за все, не стали б обробляти запити рекурсивно, навіть якщо б така вимога стояла в запиті).
  
Retry говорит о том, как часто вторичный сервер должен пытаться прочитать данные, если первичный сервер не отвечает.
+
Іноді допускається, щоб запрошений сервер передавав ''рекурсивний'' запит "вищестоящому" DNS- серверу і чекав готової відповіді.
  
Expire говорит вторичным серверам, в течение какого времени они должны обслуживать домен, если первичный сервер не отвечает. По истечении этого времени вторичные сервера будут считать свои данные устаревшими.  
+
При ''рекурсивній'' обробці запитів усі відповіді проходять через DNS- сервер, і він дістає можливість ''кешуровати'' їх. Повторний запит на ті ж імена зазвичай не йде далі ''за кеш'' сервера, звернення до інших серверів не відбувається взагалі. Допустимий час зберігання відповідей в ''кеші'' приходить разом з відповідями(поле ''TTL'' '''ресурсного запису''').
  
Minimum задает время жизни записей по умолчанию для данной зоны.  
+
Рекурсивні запити вимагають більше ресурсів від сервера(і створюють більше трафіку), так що зазвичай приймаються від "відомих" власникові сервера вузлів(наприклад, провайдер надає можливість робити рекурсивні запити тільки своїм клієнтам, в корпоративній мережі рекурсивні запити приймаються тільки з локального сегменту). Нерекурсивні запити зазвичай приймаються від усіх вузлів мережі(і змістовна відповідь дається тільки на запити про зону, яка розміщена на вузлі, на DNS- запит про інші зони зазвичай повертаються адреси інших серверів).
  
Теперь опишем сервера имен, обслуживающие наш домен:
+
=== Зворотний DNS- запит ===
mycompany.ru. IN NS ns.mycompany.ru.
+
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- іменах старші(що знаходяться ближче до кореня) частини розташовані у кінці.
mycompany.ru. IN NS ns.provider.ru.
+
Здесь ничего сложного нет. Так как имя зоны совпадает с указанным в поле имя записи SOA, то его можно оставить пустым.  
+
  
Дальше идут записи A, описывающие ваши компьютеры и позволяющие преобразовать имена в IP-адреса.
+
== Приклад структури доменного імені ==
major IN A 192.168.0.1
+
<center>
colonel IN A 192.168.0.2
+
[[Файл:Dnsexam.jpg]]
IN HINFO "2xPIV-1.7 Win2K"
+
</center>
general.mycompany.ru. IN A 192.168.0.3
+
Першочерговим завданням DNS-сервера є забезпечення трансляції доменних імен в IP-адреси. Для адресації вузлів Інтернету використовуються спеціальні числові «коди» - IP-адреси. Система доменних імен якраз служить для виконання перетворень між символьними і числовими адресами. Традиційна IP-адреса може бути записана за допомогою чотирьох чисел в десятковій системі числення, наприклад: 192.168.175.13 або 194.85.92.93.  
Здесь сложного тоже ничего нет — имена могут быть относительные или "абсолютные", можно добавить записи о конфигурации машины (пропущенное имя в записи HINFO говорит о том, что имеется в виду предыдущее имя). Не забудьте добавить записи
+
localhost. IN A 127.0.0.1
+
localhost IN CNAME localhost.
+
mycompany.ru. IN A 192.168.0.1
+
Первая отдает адрес 127.0.0.1 любой машине, запросившей имя localhost, вторая — localhost.mycompany.ru, а третья говорит, куда послать клиента, который хочет попасть на mycompany.ru
+
  
Записи CNAME позволяют дать машинам удобные или значащие имена. Например:
+
DNS дозволяє зіставити числову IP-адресу і символьну, наприклад: 194.85.92.93 = test.ru. При цьому символьна адреса в DNS являє собою текстовий рядок, складений за особливими правилами. Найважливіше з цих правил - ієрархія доменів.
ftp IN CNAME general говорит, что ftp.mycompany.ru живет по адресу 192.168.0.3. CNAME удобно использовать, если вы меняете имя машины, но хотите оставить доступ для клиентов, которые помнят старое имя. Удобный трюк с использованием CNAME заключается в назначении коротких имен частоиспользуемым адресам. Например, прописав ls IN CNAME www.listsoft.ru., вы сможете заходить на ListSoft просто набирая ls в качестве адреса.  
+
  
Записи MX нужны для того, чтобы указать, куда пересылать почту. В этих записях добавляется приоритет — чем он меньше, тем выше приоритет машины. Приоритеты нужны для того, чтобы можно было задать несколько записей и перенаправить почту на альтернативный сервер, если основной не работает. MX запись должна быть указана для домена в целом и, возможно, для каждой машины в отдельности. Сложного тут тоже ничего нет за одним исключением: очень часто встречается неправильно использование метасимвола "*". Запись "*.mycompany.ru." означает не "любая машина домена mycompany.ru", а "любая машина, которая еще не была описана". Причем, даже если использовалась не MX, а, например, A-запись, то звездочка все равно не будет работать для этой машины. Более подробно почитать об использовании метасимволов можно в RFC 1034, раздел 4.3.3 В принципе, метасимволы нужны только для того чтобы принимать почту для сети, находящейся за брандмауэром и чтобы пересылать почту в сети, не подключенные к Интернету (например, работающие через UUCP). Так как записи DNS меняются довольно редко, то имеет смысл прописать MX записи для всех машин, описанных записями A.
+
Система адрес DNS має деревоподібну структуру. Вузли цієї структури називаються доменами. Кожен домен може містити безліч «підлеглих» доменів. Основою даної ієрархічної структури імен т.зв. "Корінь дерева" є точка ("."). Корінь єдиний для всіх доменів. Як правило, при введенні URL, крапка наприкінці адреси не ставиться, проте вона використовується в описах DNS. Цікаво, що про існування кореневого домену зараз пам'ятають лише фахівці. Втім, його можна і вказати. Адресний рядок із зазначенням кореневого домену виглядає, наприклад, так: «site.test.ru.» - тут кореневий домен відділений останньої, крайньої праворуч, крапкою.  
  
mycompany.ru. IN MX 10 relay
+
Нижче кореня лежать домени першого рівня (зони). Їх небагато - COM, NET, ORG, MIL, BIZ, INFO, GOV (є ще кілька) і домени держав, наприклад, RU. Ще нижче знаходяться домени другого рівня, наприклад, test.ru. Ще нижче - третього і т.д. Рівні розділяються крапками.  
mycompany.ru. IN MX 20 mycompany.ru.
+
mycompany.ru. IN MX 30 mail.provider.ru.
+
general.mycompany.ru. IN A 192.168.0.3
+
IN MX 10 mycompany.ru.  
+
  
На этом создание файла зоны можно считать законченным. Но остается более увлекательное занятие: описание реверсной зоны. Если предыдущий файл позволяет определить IP-адрес по имени, то теперь надо сделать так, чтобы по IP-адресу можно было "вычислить" имя. Отсутствие реверсной зоны является довольно типичной ошибкой и может приводить к самым разным ошибкам — начиная от сбоев FTP-серверов и заканчивая классификацией отправленных писем как спама.  
+
DNS сервер не ізольований. Кожному DNS-СЕРВЕРУ відомі адреси кореневих DNS-серверів. При запиті, DNS-сервер або сам знає відповідь, або знає у кого запитати. Якщо простежити проходження запиту, картина складається досить цікаво. При налаштуванні користувачеві вказується два DNS сервера (первинний і вторинний). Адреси dns серверів вказується провайдером.  
  
Для обратного преобразования используются записи PTR. Но не торопитесь их вписывать — тут есть одна хитрость: они пишутся в отдельном специальном домене верхнего уровня, с названием IN-ADDR.ARPA. Домен этот был создан для того, чтобы и для прямого, и для обратного преобразований можно было использовать одни и те же программные модули. Дело в том, что "мнемонические" имена пишутся слева направо: www.listsoft.ru означает, что www находится в listsoft, а listsoft — в ru. IP-адреса пишутся наоборот: 195.242.9.4 означает, что машина 4 находится в подсети 9, которая является частью 195.242 И для сохранения "единого стиля" адресов для обратного преобразования используются имена вида 4.9.242.195.IN-ADDR.ARPA (обратите внимание, что IP-адрес записан в обратном порядке).
+
Користувач відправляє запит первинному DNS серверу. Сервер, у свою чергу, отримавши запит, або відповідає, якщо відповідь йому відома, або відправляє запит на вищого рівня сервер. Якщо вищого рівня сервер не відомий, запит відправляється на кореневий DNS сервер. Так виглядає висхідна (восходящяя) ієрархія. Далі запит починає спускатися вниз від кореневого сервера до сервера першого рівня, той – до СЕРВЕРУ другого рівня і т.д.  
  
Итак, мы создаем еще один файл зоны (для зоны, например, 0.168.192.IN-ADDR.ARPA), копируем в него запись SOA (а заодно и NS), после чего начинаем писать:
+
DNS сервера бувають рекурсивними і нерекурсивними. Рекурсивні сервера завжди повертають користувачеві відповідь. Тобто, вони самостійно опитують інші DNS сервера. Рекурсивні сервера зручно використовувати в локальних мережах. Вони кешують проміжні відповіді, таким чином, при наступних запитах відповіді будуть повертатися набагато швидше. Нерекурсивні сервера повертають користувачеві всі відсилання, так що клієнт повинен самостійно опитувати вказаний сервер. Нерекурсивні сервера зазвичай стоять на верхніх щаблях ієрархії. Вони отримують багато запитів, а для кешування потрібні багато ресурсів. Таким чином, кешування на таких серверах не проводиться.
1 IN PTR major.mycompany.ru.
+
2 IN PTR colonel.mycompany.ru.
+
...
+
Можно задавать не только относительные, но и абсолютные имена:
+
3.0.168.192.IN-ADDR.ARPA. IN PTR general.mycompany.ru.
+
  
Не забудьте еще задать обратное преобразование для 127.0.0.1.
+
== Записи DNS ==
 +
Записи DNS, або ''Ресурсні записи'' (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожен ресурсний запис складається з наступних полів:
  
Обратите внимание на то, что право на ведение "прямого" домена не зависит от провайдера — его выдает организация, ведающая распределением имен в нужном вам домене. А вот пул IP-адресов находится в ведении провайдера, и именно провайдер делегирует (или не делегирует) вам права на ведение реверсной зоны. В связи с тем, что зачастую клиентам выдается не целая сеть класса «C», а ее часть, то и реверсная зона находится на сервере провайдера. Так что вам придется наладить с ним взаимодействие в области обновления данных.  
+
* '''''Ім'я''''' (NAME) - доменне ім'я, до якого прив'язана або якому «належить» дана ресурсна запис. Ім'я буває абсолютним (FQDN - Fully Qualified Domain Name) і відносним. Абсолютне ім'я закінчується крапкою. Якщо ж ім'я вказати без крапки в кінці, це ім'я буде вважатися відносним і йому автоматично додається ім'я поточного домену;
 +
* '''''TTL''''' (Time To Live) - допустимий час зберігання даної ресурсної записи в кеші не відповідального DNS-сервера. Даний параметр вказується в секундах;
 +
* '''''Тип''''' (TYPE) ресурсного запису - визначає формат і призначення даного ресурсного запису;
 +
* '''''Клас''''' (CLASS) ресурсного запису; теоретично вважається, що DNS може використовуватися не тільки з TCP / IP, але і з іншими типами мереж, код у полі клас визначає тип мережі;
 +
* '''''Довжина поля даних''''' (RDLEN);
 +
* '''''Поле даних''''' (RDATA), формат і зміст якого залежить від типу запису.
  
Напоследок — одно маленькое замечание. Исследование DNS является одним из первых этапов "изучения сети" при подготовке ее взлома. Чаще всего используется перенос зоны, при котором все записи зоны передаются на компьютер "исследователя", где он их может изучать в спокойной обстановке. Поэтому имеет смысл (помимо всего прочего) настроить брандмауэр на запрет TCP-соединений по 53 порту с несанкционированных адресов (в запросах на определение имен используется UDP, а для переноса зоны — TCP).
+
Найбільш важливі типи DNS-записів:
  
P.S. Для того чтобы посмотреть, что записано в DNS, используется команда nslookup (она есть и в UNIX, и в Windows).  
+
* '''''Запис 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''''' опис "заліза" комп'ютера
  
http://hostinfo.ru/articles/57/
+
'''Базовий формат запису виглядає так:'''
http://domaintimes.net/chto-takoe-dns-server-i-kak-on-rabotaet/
+
  
 +
[ім'я] [час] [клас] [тип] [дані]
 +
 +
== Зарезервовані доменні імена ==
 +
Документ 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]]
 +
 +
== [[Сторінка питань з DNS/DHCP]] ==
 +
 +
[[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