Відмінності між версіями «DNS»
Lithic (обговорення • внесок) |
|||
| (не показані 49 проміжних версій 4 учасників) | |||
| Рядок 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 підтримується за допомогою ієрархії 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). | |
| + | <center> | ||
| + | [[Файл:workDNS.jpg]] | ||
| + | </center> | ||
| − | ''''' | + | '''Ключовими поняттями 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'' - авторитетний), на якому розташована інформація про домен. | |
| − | + | Ім'я та IP-адреса не тотожні - одина IP-адреса може мати безліч імен, що дозволяє підтримувати на одному комп'ютері безліч веб-сайтів (це називається віртуальний хостинг). Зворотне теж справедливо - одному імені можна порівнювати безліч IP-адрес: це дозволяє створювати балансування навантаження. | |
| − | + | Для підвищення стійкості системи використовується безліч серверів, що містять ідентичну інформацію, а в протоколі є засоби, що дозволяють підтримувати синхронність інформації, розташованої на різних серверах. Існує 13 кореневих серверів, їх адреси практично не змінюються. | |
| − | + | === [[Рекурсія]] === | |
| − | + | Терміном '''Рекурсія''' в DNS означають алгоритм поведінки '''DNS- сервера''', при якому сервер виконує від імені клієнта повний пошук потрібної інформації в усій системі DNS, при необхідності звертаючись до іншим '''DNS- серверам'''. | |
| − | + | '''DNS- запит''' може бути ''рекурсивним'' - що вимагає повного пошуку, - і ''нерекурсивним'' (чи ''ітеративним'') - що не вимагає повного пошуку. | |
| − | + | Аналогічно, '''DNS- сервер''' може бути ''рекурсивним'' (що уміє виконувати повний пошук) і ''нерекурсивним'' (що не уміє виконувати повний пошук). Деякі програми DNS- серверів, наприклад, BIND, можна конфігурувати так, щоб запити одних клієнтів виконувалися ''рекурсивно'', а запити інших - ''нерекурсивний''. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | При відповіді на ''нерекурсивний'' запит, а також - при невмінні або забороні виконувати ''рекурсивні'' запити, - DNS- сервер або повертає дані про зону, за яку він '''ответствен''', або повертає адреси серверів, які мають великий об'єм інформації про запрошену зону, чим сервер, що відповідає, найчастіше - адреси кореневих серверів. | |
| − | + | У разі ''рекурсивного'' запиту '''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) або запис адреси | + | * '''''Запис 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) або запис покажчика | + | * '''''Запис PTR''''' (''pointer'') або запис покажчика, що зв'язує IP адресу хоста з його канонічним ім'ям. Запит у домені '''''in-addr.arpa''''' на IP хоста в ''reverse'' формі поверне ім'я ('''FQDN''') даного хоста. |
| − | *Запис SOA (Start of Authority) або початковий запис зони вказує, на якому сервері зберігається еталонна інформація | + | * '''''Запис 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]] == | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | |||
[[category:Комп'ютерні мережі]] | [[category:Комп'ютерні мережі]] | ||
Поточна версія на 17:59, 16 січня 2014
| Назва: | 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).
Ключовими поняттями 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- іменах старші(що знаходяться ближче до кореня) частини розташовані у кінці.
Приклад структури доменного імені
Першочерговим завданням 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. Порядок реєстрації та вимоги залежать від обраної доменної зони. Реєстрація домену може бути виконана як організацією-реєстратором, так і приватною особою, якщо це дозволяють правила обраної доменної зони.
