Відмінності між версіями «DNS»
Рядок 35: | Рядок 35: | ||
* '''''DNS-запит''''' (англ. DNS query) - запит від клієнта (або сервера) серверу. Запит може бути ''рекурсивним'' або ''нерекурсивним''. | * '''''DNS-запит''''' (англ. DNS query) - запит від клієнта (або сервера) серверу. Запит може бути ''рекурсивним'' або ''нерекурсивним''. | ||
− | Система DNS містить ієрархію DNS-серверів, відповідну ієрархії зон. Кожна зона підтримується як мінімум одним авторитетним сервером DNS (від англ. Authoritative - авторитетний), на якому розташована інформація про домен. | + | Система DNS містить ієрархію DNS-серверів, відповідну до ієрархії зон. Кожна зона підтримується як мінімум одним авторитетним сервером DNS (від англ. ''Authoritative'' - авторитетний), на якому розташована інформація про домен. |
− | Ім'я та IP-адреса не тотожні - | + | Ім'я та IP-адреса не тотожні - одина IP-адреса може мати безліч імен, що дозволяє підтримувати на одному комп'ютері безліч веб-сайтів (це називається віртуальний хостинг). Зворотне теж справедливо - одному імені можна порівнювати безліч IP-адрес: це дозволяє створювати балансування навантаження. |
Для підвищення стійкості системи використовується безліч серверів, що містять ідентичну інформацію, а в протоколі є засоби, що дозволяють підтримувати синхронність інформації, розташованої на різних серверах. Існує 13 кореневих серверів, їх адреси практично не змінюються. | Для підвищення стійкості системи використовується безліч серверів, що містять ідентичну інформацію, а в протоколі є засоби, що дозволяють підтримувати синхронність інформації, розташованої на різних серверах. Існує 13 кореневих серверів, їх адреси практично не змінюються. | ||
− | Протокол DNS використовує для роботи TCP-або UDP-порт 53 для відповідей на запити. Традиційно запити і відповіді відправляються у вигляді однієї UDP датаграми. TCP використовується для AXFR-запитів. | + | Протокол DNS використовує для роботи TCP-або UDP-порт 53 для відповідей на запити. Традиційно запити і відповіді відправляються у вигляді однієї UDP датаграми. TCP використовується для '''AXFR'''-запитів. |
− | + | ||
− | + | === Рекурсія === | |
− | DNS- | + | Терміном Рекурсія в DNS позначають алгоритм поведінки '''DNS-сервера''', при якому сервер виконує від імені клієнта повний пошук потрібної інформації в усій системі DNS, при необхідності звертаючись до інших '''DNS-серверів'''. |
− | + | '''DNS-запит''' може бути ''рекурсивним'' - вимагають повного пошуку, - і ''нерекурсивним'' - не вимагають повного пошуку. | |
− | При відповіді на нерекурсивний запит, а також - при невмінні або заборону виконувати рекурсивні запити, - DNS-сервер або повертає дані про зону, за яку ти відповідальний, або повертає адреси серверів, які володіють великим обсягом інформації про запитаної зоні, ніж відповідає сервер, найчастіше - адреси кореневих серверів. | + | Аналогічно, '''DNS-сервер''' може бути рекурсивним (який вміє виконувати повний пошук) і нерекурсивним (не вміє виконувати повний пошук). Деякі програми DNS-серверів, наприклад, BIND, можна настроїти так, щоб запити одних клієнтів виконувалися рекурсивно, а запити інших - нерекурсивний. |
+ | |||
+ | При відповіді на ''нерекурсивний'' запит, а також - при невмінні або заборону виконувати ''рекурсивні'' запити, - DNS-сервер або повертає дані про зону, за яку ти відповідальний, або повертає адреси серверів, які володіють великим обсягом інформації про запитаної зоні, ніж відповідає сервер, найчастіше - адреси кореневих серверів. | ||
У випадку рекурсивного запиту DNS-сервер запитує сервери (у порядку убування рівня зон в імені), поки не знайде відповідь або не виявить, що домен не існує. (На практиці пошук починається з найбільш близьких до шуканого DNS-серверів, якщо інформація про них є в кеші і не застаріла, сервер може не запитувати інші DNS-сервери.) | У випадку рекурсивного запиту DNS-сервер запитує сервери (у порядку убування рівня зон в імені), поки не знайде відповідь або не виявить, що домен не існує. (На практиці пошук починається з найбільш близьких до шуканого DNS-серверів, якщо інформація про них є в кеші і не застаріла, сервер може не запитувати інші DNS-сервери.) | ||
Рядок 56: | Рядок 57: | ||
Розглянемо на прикладі роботу всієї системи. | Розглянемо на прикладі роботу всієї системи. | ||
− | Припустимо, ми набрали в браузері адресу ru.wikipedia.org. Браузер запитує у сервера 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 по імені: | У даному випадку при вирішенні імені, тобто в процесі пошуку IP по імені: | ||
− | + | * Браузер відправив відомому йому DNS-сервера рекурсивний запит - у відповідь на такий тип запиту сервер зобов'язаний повернути «готовий результат», тобто IP-адресу, або повідомити про помилку; | |
− | + | * DNS-сервер, який отримав запит від браузера, послідовно відправляв нерекурсівние запити, на які отримував від інших DNS-серверів відповіді, поки не отримав відповідь від сервера, відповідального за запитану зону; | |
− | + | * Інші згадувані DNS-сервери обробляли запити нерекурсивний (і, швидше за все, не стали б обробляти запити рекурсивно, навіть якщо б така вимога стояло в запиті). | |
Іноді допускається, щоб, запитаний сервер передавав рекурсивний запит «вищестоящому» DNS-сервера і чекав готової відповіді. | Іноді допускається, щоб, запитаний сервер передавав рекурсивний запит «вищестоящому» DNS-сервера і чекав готової відповіді. | ||
Рядок 69: | Рядок 70: | ||
Рекурсивні запити вимагають більше ресурсів від сервера (і створюють більше трафіку), так що зазвичай приймаються від «відомих» власнику сервера вузлів (наприклад, провайдер надає можливість робити рекурсивні запити тільки своїм клієнтам, в корпоративній мережі рекурсивні запити приймаються тільки з локального сегменту). Нерекурсівние запити зазвичай приймаються від усіх вузлів мережі (і змістовну відповідь дається тільки на запити про зону, яка розміщена на сайті, на DNS-запит про інших зонах зазвичай повертаються адреси інших серверів). | Рекурсивні запити вимагають більше ресурсів від сервера (і створюють більше трафіку), так що зазвичай приймаються від «відомих» власнику сервера вузлів (наприклад, провайдер надає можливість робити рекурсивні запити тільки своїм клієнтам, в корпоративній мережі рекурсивні запити приймаються тільки з локального сегменту). Нерекурсівние запити зазвичай приймаються від усіх вузлів мережі (і змістовну відповідь дається тільки на запити про зону, яка розміщена на сайті, на 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-адреси, але він також може виконувати зворотний процес. Для цього використовуються вже наявні кошти DNS. Справа в тому, що із записом DNS можуть бути зіставлені різні дані, в тому числі і будь-яке символьне ім'я. Існує спеціальний домен in-addr.arpa, записи в якому використовуються для перетворення IP-адрес в символьні імена. Наприклад, для отримання DNS-імені для адреси 11.22.33.44 можна запросити у DNS-сервера запис 44.33.22.11.in-addr.arpa, і той поверне відповідне символьне ім'я. Зворотний порядок запису частин IP-адреси пояснюється тим, що в IP-адресах старші біти розташовані на початку, а в символьних DNS-іменах старші (що знаходяться ближче до кореня) частини розташовані в кінці. | ||
− | |||
− | + | == Записи DNS == | |
Записи DNS, або Ресурсні записи (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожна ресурсна запис складається з наступних полів: | Записи DNS, або Ресурсні записи (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожна ресурсна запис складається з наступних полів: | ||
Рядок 98: | Рядок 97: | ||
* Запис SRV (server selection) вказує на сервери для сервісів, використовується, зокрема, для Jabber і Active Directory. | * Запис SRV (server selection) вказує на сервери для сервісів, використовується, зокрема, для Jabber і Active Directory. | ||
− | + | ||
+ | == Зарезервовані доменні імена == | ||
+ | |||
Документ RFC 2606 (Reserved Top Level DNS Names - Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використовувати в якості прикладів (наприклад, в документації), а також для тестування. Крім example.com, example.org і example.net, до цієї групи також входять test, invalid та ін | Документ RFC 2606 (Reserved Top Level DNS Names - Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використовувати в якості прикладів (наприклад, в документації), а також для тестування. Крім example.com, example.org і example.net, до цієї групи також входять test, invalid та ін | ||
Рядок 104: | Рядок 105: | ||
Доменне ім'я може складатися тільки з обмеженого набору ASCII символів, дозволяючи набрати адресу домену незалежно від мови користувача. ICANN затвердив засновану на Punycode систему IDNA, перетворюючу будь-який рядок в кодуванні Unicode в допустимий DNS набір символів. | Доменне ім'я може складатися тільки з обмеженого набору ASCII символів, дозволяючи набрати адресу домену незалежно від мови користувача. ICANN затвердив засновану на Punycode систему IDNA, перетворюючу будь-який рядок в кодуванні Unicode в допустимий DNS набір символів. | ||
− | + | ||
+ | == Програмне забезпечення DNS == | ||
+ | |||
Сервери імен: | Сервери імен: | ||
Рядок 117: | Рядок 120: | ||
* MyDNS [7] | * MyDNS [7] | ||
− | + | == Інформація про домен == | |
+ | |||
Багато доменів верхнього рівня підтримують сервіс whois, який дозволяє дізнатися, кому делеговано домен і іншу технічну інформацію. | Багато доменів верхнього рівня підтримують сервіс whois, який дозволяє дізнатися, кому делеговано домен і іншу технічну інформацію. | ||
− | + | ||
+ | == Реєстрація домену == | ||
+ | |||
Реєстрація домену - процедура отримання доменного імені. Полягає у створенні записів, що вказують на адміністратора домену, в базі даних DNS. Порядок реєстрації та вимоги залежать від обраної доменної зони. Реєстрація домену може бути виконана як організацією-реєстратором, так і приватною особою [2], якщо це дозволяють правила обраної доменної зони. | Реєстрація домену - процедура отримання доменного імені. Полягає у створенні записів, що вказують на адміністратора домену, в базі даних DNS. Порядок реєстрації та вимоги залежать від обраної доменної зони. Реєстрація домену може бути виконана як організацією-реєстратором, так і приватною особою [2], якщо це дозволяють правила обраної доменної зони. |
Версія за 09:09, 19 жовтня 2010
DNS (англ. Domain Name System - система доменних імен) - це розподілена комп'ютерна система для отримання інформації про домени. Найчастіше використовується для отримання IP-адреси по імені хоста (комп'ютера або пристрою), отримання інформації про маршрутизацію пошти , обслуговуваних вузлах для протоколів у домені (SRV-запис).
Розподілена база даних DNS підтримується за допомогою ієрархії DNS-серверів, взаемодіючих за певним протоколом.
Основою DNS є представлення про ієрархічну структуру доменного імені та зонах. Кожен сервер, водповідаючий за ім'я, може делегувати відповідальність за подальшу частину домену іншому серверу (з адміністративної точки зору - іншій організації або людині), що дозволяє покласти відповідальність за актуальність інформації на сервери різноманітних організацій (людей), відповідаючи тільки за «свою» частину доменного імені.
Зміст
Ключові характеристики 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 є:
- Домен (англ. 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 використовує для роботи TCP-або UDP-порт 53 для відповідей на запити. Традиційно запити і відповіді відправляються у вигляді однієї UDP датаграми. TCP використовується для AXFR-запитів.
Рекурсія
Терміном Рекурсія в 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-адресу, або повідомити про помилку;
- 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
Записи DNS, або Ресурсні записи (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожна ресурсна запис складається з наступних полів:
* Ім'я (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) даного хоста (див. Зворотний DNS-запит). Наприклад, (на момент написання), для IP адреси 192.0.34.164: запит запису PTR 164.34.0.192.in-addr.arpa поверне його канонічне ім'я referrals.icann.org. З метою зменшення обсягу небажаної кореспонденції (спаму) багато серверів-одержувачів електронної пошти можуть перевіряти наявність PTR запису для хоста, з якого відбувається відправлення. У цьому випадку PTR запис для IP адреси повинен відповідати імені відправляючого поштового сервера, яким він представляється в процесі SMTP сесії. * Запис SOA (Start of Authority) або початковий запис зони вказує, на якому сервері зберігається еталонна інформація про даний домен, містить контактну інформацію особи, відповідального за дану зону, таймінги (параметри часу) кешування зонної інформації та взаємодії DNS-серверів. * Запис SRV (server selection) вказує на сервери для сервісів, використовується, зокрема, для Jabber і Active Directory.
Зарезервовані доменні імена
Документ 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) [1] * Djbdns (Daniel J. Bernstein 's DNS) [2] * MaraDNS [3] * NSD (Name Server Daemon) [4] * PowerDNS [5] * OpenDNS [6] * Microsoft DNS Server (в серверних версіях операційних систем Windows NT) * MyDNS [7]
Інформація про домен
Багато доменів верхнього рівня підтримують сервіс whois, який дозволяє дізнатися, кому делеговано домен і іншу технічну інформацію.
Реєстрація домену
Реєстрація домену - процедура отримання доменного імені. Полягає у створенні записів, що вказують на адміністратора домену, в базі даних DNS. Порядок реєстрації та вимоги залежать від обраної доменної зони. Реєстрація домену може бути виконана як організацією-реєстратором, так і приватною особою [2], якщо це дозволяють правила обраної доменної зони.