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

Версія за 12:09, 20 листопада 2018

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) Криптографічні підпису DNSSEC застосовуються до даних по зоні, динамічним оновленням і транзакцій DNS. Крім того, вони використовуються для підтвердження відсутності даних DNS. DNSSEC передбачає три нові записи ресурсів - KEY RR, SIG RR і NXT RR.

KEY RR містить відкритий ключ, що належить імені домена, вказаною в KEY RR. Це не сертифікат відкритого ключа. Механізм забезпечення можливостей пошуку сертифікатів відкритих ключів передбачається DNSSEC WG, але не для цілей захисту даних DNS. Він надається в якості додаткового бонусу, завдяки якому DNS може застосовуватися для запиту сертифікатів відкритих ключів на все, що може бути представлено за допомогою імені домену. Цю можливість забезпечує CERT RR.

SIG RR містить переважно криптографічний підпис, дату закінчення терміну придатності підпису і визначення даних DNS, до яких ця підпис ставиться. NXT RR дозволяє перевірити (за рахунок використання криптографії), що RR для даного імені DNS не існує. Таким чином, відсутність даної RR може бути підтверджено доказово.

Іншим аспектом DNSSEC є підпис транзакції (Transaction Signature, TSIG). TSIG відрізняється від інших підписів DNS тим, що вона створюється з використанням шифрування з секретними ключами. Ми розглянемо TSIG пізніше.

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

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

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

Підтримка різноманітних типів інформації (SRV-записи)

SRV - одна з різновидів записів в DNS. Вказує місце розташування серверів для різних сервісів.

SRV запис складається з следущих частин:

service proto priority weight port hostname, де

service - ім'я сервісу. Наприклад _xmpp-server або _sip

proto - ім'я протоколу. Зазвичай _tcp або _udp

priority - пріоритет запису

weight - вага записи. Використовується для записів з однаковим пріоритетом

port - порт на сервері.

hostname - ім'я сервера.

Приклад SRV запису

_xmpp-server._tcp.peterhost.ru SRV 100 0 5269 xmpp-s.peterhost.ru., де

_xmpp-server - сервіс (xmpp сервіс)

tcp - протокол доступу

100 - пріоритет

0 - вага

xmpp-s.peterhost.ru - ім'я сервера

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

Основна область застосування 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 (англ. reverse DNS lookup) — особлива доменна зона, призначена для визначення імені вузла за його IP-адресою за допомогою PTR-запису. Адреса вузла AAA.BBB.CCC.DDD перекладається в зворотній нотації в DDD.CCC.BBB.AAA.in-addr.arpa. Завдяки ієрархічній моделі управління іменами з'являється можливість делегувати управління зоною власнику діапазону IP-адрес. Для цього в записах авторитетного DNS-сервера вказують, що за зону CCC.BBB.AAA.in-addr.arpa (тобто за мережу AAA.BBB.CCC.000/24) відповідає окремий сервер.

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 та ін.

Національні домени

(ccTLD) – національні домени верхнього рівня, які відповідають кожен своїй окремій країні.

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

Доменне ім'я може складатися тільки з обмеженого набору 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