DNS сервер BIND (теорія)

1. ресурсні записи
2. Запис ресурсу складається з наступних полів:
3. сервери DNS
4. Клієнти DNS (resolver)
5. запити DNS
6. Відповіді DNS сервера
7. Зворотне перетворення імен
8. Реєстрація доменних імен
9. резюме
10. Що ще почитати:

Основна мета DNS - це відображення доменних імен в IP адреси і навпаки - IP в DNS. У статті я розгляну роботу DNS сервера BIND (Berkeley Internet Name Domain, раніше: Berkeley Internet Name Daemon), як самого (не побоюся цього слова) поширеного. BIND входить до складу будь-якого дистрибутива UNIX. Основу BIND становить демон named, який для своєї роботи використовує порт UDP / 53 і для деяких запитів TCP / 53.

Основні поняття Domain Name System

Історично, до появи доменної системи імен роль інструменту дозволу символьних імен в IP виконував файл / etc / hosts, який і в даний час грає далеко не останню роль в цій справі. Але з ростом кількості хостів в глобальній мережі, відстежувати і обслуговувати базу імен на всіх хостах стало нереально важко. В результаті придумали DNS, що представляє собою ієрархічну, розподілену систему доменних зон. Давайте розглянемо структуру Системи доменних Імен на ілюстрації:

Доменна структура DNS являє собою деревоподібну ієрархію, що складається з вузлів, зон, доменів, піддоменів і ін. Елементів, про які піде мова. «Вершиною» доменної структури є коренева зона. Налаштування кореневої зони розташовані на безлічі серверів / дзеркал, розміщених по всьому світу і містять інформацію про всіх серверах кореневої зони, а так само відповідають за домени першого рівня (ru, net, org і ін). Інформація про сервери кореневої зони розташована на даному сайті кореневих серверів . Налаштування кореневої зони завжди доступні тут . Сервери кореневої зони обробляють і відповідають на запити, видаючи інформацію тільки про доменах першого рівня (тобто відповідають на будь-які запити, як на нерекурсівние)! Отже, вже багато раз повторилося слово зона. Пора цей термін пояснити.

Зона - це будь-яка частина дерева системи доменних імен, що розміщується як єдине ціле на деякому DNS-сервері. Зону, для більшого розуміння, можна назвати «зоною відповідальності». Метою виділення частини дерева в окрему зону є передача відповідальності (Делегування) за цю гілку іншій особі або організації. На ілюстрації, приклади зон виділені синім градієнтом (зона name., Зона k-max.name. З усім підлеглими ресурсами, www.openoffice.org з усім підлеглими піддоменами і ресурсами). На ілюстрації виділені не всі зони, а лише деякі для загального розуміння і уявлення. У кожній зоні є, принаймні, один авторитетний сервер DNS, який зберігає ВРЮ інформацію про зону, за яку він відповідає.

Домен - це іменована гілка або поддерево в дереві імен DNS, тобто це певний вузол, що включає в себе всі підлеглі вузли. Наступна цитата з книги Linux Network Administrators Guide добре прояснює картину щодо різниці між зоною і доменом:

Таким чином, простір імен роздроблене на зони (zones), кожна з яких керується своїм доменом. Зверніть увагу на відмінність між зоною (zone) і доменом (domain): домен groucho.edu зачіпає всі машини в університеті Groucho Marx, в той час як зона groucho.edu включає тільки хости, які працюють в безпосередньо комп'ютерному центрі, наприклад у відділі математики . Хост в відділі фізики належать іншій зоні, а саме physics.groucho.edu.

Кожен вузол в ієрархії DNS відділений від свого батька точкою. Якщо провести аналогію з файлової системою Linux, система доменних імен має схожу структуру, за тим винятком, що роздільник в файлової системі - слеш, а в DNS - точка. А так же DNS адресу читається справа наліво (від кореневого домена до імені хоста) на відміну від шляху в файлової системі Linux. Доменне ім'я починається з точки (кореневого домена) і проходить через домени першого, другого і якщо потрібно третього і т.д. рівнів і завершується ім'ям хоста. Т.ч. доменне ім'я повністю відображає структуру ієрархії DNS. Часто (я б сказав - завжди в повсякденному житті), остання точка (позначення кореневого домена) в доменному імені опускається (тобто в браузері ми вводити не k-max.nam e., А k-max.nam e). Отже, розібравши структуру доменного імені, ми непомітно підійшли до поняття FQDN.

FQDN (англ. Fully Qualifed Domain Name, повністю певне ім'я домену) - це ім'я домену, що однозначно визначає доменне ім'я і включає в себе імена всіх батьківських доменів ієрархії DNS, в тому числі і кореневого. Своєрідний аналог абсолютного шляху в файлової системі. Давайте розберемо вищесказане на прикладі імені домена mail.k-max.name:

mail.k-max.name.

| | | | | | | | | + -Корневой домен | | | + --- домен першого рівня | | + ------ точка, що розділяє домени / частини FQDN | + --------- домен другого рівня + --------------- піддомен / домен третього рівня, можливо - ім'я хоста

Різниця між FQDN і звичайним доменним (неFQDN) ім'ям з'являється при іменуванні доменів другого, третього (і т. Д.) Рівня. Для отримання FQDN потрібно обов'язково вказати в доменному імені домени вищого рівня (наприклад, mail є доменним ім'ям, проте FQDN ім'я виглядає як mail.k-max.name.). Максимальний розмір FQDN - 255 байт, з обмеженням в 63 байта на кожне ім'я домену.

Піддомени, коротко кажучи, це - підлеглі домени. За великим рахунком, всі домени в інтернеті є підлеглими за винятком кореневого. Наприклад домен k-max є піддоменом домену name, а name, в свою чергу - піддоменом кореневого домена.

Отже, на схемі вище ми розглянули кореневої домен, які проходитимуть у ієрархії йдуть домени першого / верхнього рівня, вони ж TLD, вони ж Top-Level Domain. До даних доменів відносяться національні домени (ru., Ua. І ін) і загальні домени (com., Net., Та ін). Існують так само спеціалізовані домени, які не опубліковані в системі DNS, але використовуються програмами (домен .onion використовується анонімної мережею Tor для перехоплення і подальшої маршрутизації звернень до прихованих сервісів цієї мережі). Ще є т.зв. зарезервовані доменні імена, визначені в RFC 2606 (Reserved Top Level DNS Names - Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використовувати в якості прикладів (наприклад, в документації), а також для тестування. До таких імен належать наприклад example.com, example.org і example.net, а також test, invalid і ін. Нижче по ієрархії, як видно, йдуть домени третього рівня і т.д. Закінчується доменна ієрархія - іменами хостів, які задаються відповідними ресурсними записами або хостової записами.

ресурсні записи

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

Запис ресурсу складається з наступних полів:

• ім'я (NAME) - доменне ім'я, до якого прив'язана або якому «належить» дана ресурсна запис, або IP адреса. При відсутності даного поля, запис ресурсу успадковується від попереднього запису.
• Time To Live (TTL) - дослівно «час життя» записи, час зберігання записи в кеші DNS (після зазначеного часу запис видаляється), дане поле може не вказуватися в індивідуальних записах ресурсів, але тоді воно повинно бути зазначено на початку файлу зони і буде успадковуватися усіма записами.
• клас (CLASS) - визначає тип мережі, (в 99,99% випадках використовується IN (що означає - Internet). Дане поле було створено з припущення, що DNS може працювати і в інших типах мереж, крім TCP / IP)
• тип (TYPE) - тип запису синтаксис і призначення записи
• дані (DATA) - різна інформація, формат і синтаксис якої визначається типом.

При цьому, можливо використовувати такі символи:

• ; - Вводить коментар
• # - Також вводить коментарі (тільки у версії BIND 4.9)
• @ - Ім'я поточного домену
• () - Дозволяють даними займати кілька рядків
• * - Метасимвол (тільки в поле ім'я)

З усім набором ресурсних записів можна ознайомитися в wikipedia . Найбільш часто застосовуються ресурсні записи наступними (далі, ми обов'язково розглянемо їх на практиці):

Давайте розглянемо, що є Делегування. Делегування (коректніше сказати делегування відповідальності) - це операція передачі відповідальності за частину дерева доменних імен (зону) іншій особі або організації. За рахунок делегування, в DNS забезпечується распределенность адміністрування і зберігання зон. Технічно, делегування полягає у виділенні будь-якої частини дерева в окрему зону, і розміщенні цієї зони на DNS-сервері, що належить іншій особі або організації. При цьому, в батьківську зону включаються «склеюють» ресурсні записи (NS і А), що містять покажчики на авторитативні DNS-сервера дочірньої зони, а вся інша інформація, що відноситься до дочірньої зоні, зберігається вже на DNS-серверах дочірньої зони. Наприклад, на ілюстрації кореневої домен делегує повноваження серверів відповідає за TLD, TLD же в свою чергу, делегують повноваження управління зонами - серверам другого рівня, іноді на цьому ланцюжок закінчується, але буває, що делегування простягається до 4 і навіть 5 рівнів.

Для більшого розуміння, наведу приклад. Делегування управління піддоменом k-max.name іншій особі (в моєму випадку - хостера) призводить до створення нової зони, яка адмініструється незалежно від решти простору імен (незалежно від вищестоящого name.). Зона k-max.name після делегування повноважень тепер не залежить від name. і може містити всі (вірніше сказати - будь-які імена, які я захочу) доменні імена, які закінчуються на * .k-max.name. З іншого боку, зона name. містить тільки доменні імена, що закінчуються на * .name., але не входять в делеговані цієї зони, такі, наприклад, як k-max.name або a-lab.name або будь-яка інша. k-max.name може бути поділений на піддомени з іменами на кшталт mail.k-max.name, ftp.k-max.name і деякі з цих піддоменів можуть бути виділені в самостійні зони, і відповідальність за дані зони може так само бути делегована . Якщо ftp.k-max.name буде самостійною зоною, то зона k-max.name нічого очікувати утримувати доменні записи, які закінчуються на * .ftp.k-max.name.

Т.ч. після делегування відповідальності, інформація зберігається делегує зоною вже не включає інформацію з делегованого поддомену і його ресурсним записам хостів, а зберігає інформацію про серверах імен, які є для делегованого поддомена авторитативні. Це і є «склеюють» записи, про що я вище вже говорив. У такому випадку, якщо у DNS-сервера батьківського домену запитуються дані про адресу, що належить делегированному поддомену, у відповідь надається список DNS-серверів, які володіють відповідною інформацією.

сервери DNS

Вище, при розгляді типів ресурсних записів я згадував про первинному і вторинному сервері. Крім даних типів, існує ще один тип - кешуючий.

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

Вторинний сервер - теж є авторитетним, але він копіює головний файл зони з первинного сервера. Відмінність головного від вторинного лише в тому, що головний завантажує свою інформацію з конфігураційних файлів зони, а вторинний - завантажує (отримує) настройки зон - з головного сервера. Вторинний DNS може отримувати свої дані і від іншої вторинної сервера. Будь-який запит щодо хоста в межах зони, за яку відповідає авторитетний сервер, буде в кінці кінців переданий одному з цих серверів (головному або вторинному). Вторинних серверів може бути скільки завгодно багато. Залежно від налаштувань, головний сервер може надсилати вторинному сигнал про зміну зони, при цьому вторинний, отримавши сигнал проводить копіювання. Дана дія називається трансфер зони (zone transfer). Існує два механізми копіювання зони: повне копіювання (AXFR) і инкрементальное (incremental) копіювання зони (IXFR).

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

Можливо так само налаштувати DNS в режимі stels (т.зв. невидимий), інформацію про даний сервері неможливо отримати використовуючи прямі запити. Це може бути корисно для організації primary сервера в захищеному середовищі і тим самим захистити зону від атак на зону.

Клієнти DNS (resolver)

Як же програми на кінцевих машинах знають куди і в якому вигляді посилати запити DNS? Вони цього не знають. Для розпізнавання імен та IP адрес клієнтськими додатками використовується бібліотека Resolver. Це не якесь спеціальне додаток, це функціональність системи (ядра). Т.ч. додатки посилають системні виклики gethostbyname (2) і gethostbyaddr (2), а ядро вже на підставі налаштувань у файлі /etc/nsswitch.conf визначає яким шляхом йому далі діяти. Даний файл визначає які сервіси (будь то файл / etc / hosts або DNS) і в якому порядку використовувати. У ранніх версіях бібліотеки Linux - libc, використовувався файл /etc/host.conf. Ось фрагмент файлу, який нас цікавить:

[Email protected]

: ~ # Cat /etc/nsswitch.conf ...... hosts: files dns networks: files

Два рядки даного фрагмента вказують ядру виробляти перетворення імен хостів в IP (рядок hosts: files dns) спочатку з файлу hosts, потім силами DNS, а так само перетворення імен мереж в IP (рядок networks: files) за допомогою файлу / etc / network. можливі також параметри nis або nisplu, що визначають використовувати Network Information System (NIS) щоб знайти адресу. Порядок, в якому перераховані сервіси, визначає послідовність їх опитування.

Якщо згідно /etc/nsswitch.conf запит відправляється DNS, то буде використано стандартні з файлу /etc/resolv.conf, який визначає які сервери DNS використовувати. Ось типовий приклад файлу /etc/resolv.conf:

[Email protected]

: ~ # Cat /etc/resolv.conf nameserver 192.168.1.1 nameserver 192.168.1.2 domain examle.com

Директива nameserver визначає адресу сервера доменних імен, який буде виконувати рекурсивні запити resolver. В даному файлі вказано використовувати північ імен спочатку 192.168.1.1 потім, якщо перший не зміг обробити запит, 192.168.1.2. Рекомендується не використовувати більше 3х параметрів nameserver. Якщо опція nameserver не задана, то Резолвер спробує з'єднатися з сервером на локальному хості. Параметр domain визначає заданий за замовчуванням ім'я домену, яке буде підставлена, коли DNS не вдасться знайти ім'я хоста. Існує так само опція search, яка задає додаткові домени, в яких необхідно провести пошук і дозвіл імені хоста. Опції search і domain не можна використовувати спільно.

Крім кеша на ДНС сервері, існують кеші інтернет-браузерів, кеші Резолвер. Досить прозору картину надає Wikipedia:

запити DNS

У DNS є такі типи запитів: ітеративний (він же прямий), зворотний і рекурсивний.

Ітеративний (він же прямий, він же нерекурсивний) запит посилає доменне ім'я DNS сервера і просить повернути або IP адреса цього домену, або ім'я DNS сервера, авторитативні для цього домену. При цьому, сервер DNS НЕ опитує інші сервери для отримання відповіді. Так працюють кореневі і TLD сервери.

Рекурсивний запит посилає DNS сервера доменне ім'я і просить повернути IP адреса запитаного домену. При цьому сервер може звертатися до інших DNS серверів.

Зворотний запит посилає IP і просить повернути доменне ім'я.

Будь-DNS-server повинен відповідати на ітеративні запити. Можливо налаштувати DNS відповідати і на рекурсивні запити. Якщо DNS не налаштований відповідати на рекурсивні запити, він обробляє їх як ітеративні.

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

Давайте розберемо, що тут намальовано по кроках:

1. Клієнт (браузер, поштовий клієнт, або будь-яке інше додаток) відправляє запит Резолвер, Резолвер на підставі зазначених конфігов визначає адресу налаштованого сервера імен.
2. Резолвер надсилає запит вказаного серверу імен.
3. Сервер імен бере даний рекурсивний запит і, тому не має інформації ні про домен, ні, можливо, навіть про зону name., відправляє рекурсивний (або нерекурсивний в залежності від налаштувань) запит серверу, що відповідає за кореневу зону.
4. Сервер кореневої зони і не виконує жодних рекурсивні запити, в результаті обробляє цей запит як ітеративний і повертає ім'я та адресу сервера, авторитетного за зону name.
5. Сервер послідовно продовжує опитувати авторитативні сервера для наступних зон, в порядку убування рівня зон в імені
6. поки не отримує задовільну відповідь, даних кроків може бути більше, в залежності від довжини доменного імені
7. і «вкладеності» доменних імен.
8. У підсумку, сервер отримує необхідну відповідь від сервера імен, що зберігає необхідну ресурсну запис про хості.
9. Сервер провайдера локальної мережі повертає Резолвер клієнта запитані дані.

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

Для вирішення даного питання DNS-сервери BIND використовують метрику, звану часом відгуку (roundtrip time, або RTT), для вибору серед авторитативні DNS-серверів однієї зони. RTT визначає затримку, з якою приходить відповідь на запити від віддаленого сервера. Кожен раз, при передачі запиту віддаленим сервером DNS-сервер BIND запускає внутрішній таймер. Таймер зупиняється при отриманні відповіді, і метрика фіксується локальним сервером. Якщо доводиться вибирати один з декількох авторитативні серверів, вибір падає на сервер з найменшим показником RTT.

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

Відповіді DNS сервера

Відповіді DNS бувають наступного типу:

• Авторитативні відповідь (authoritative response) приходить від серверів, які є відповідальними за зону.
• Неавторітатівний відповідь (non authoritative response) приходить від серверів, які не відповідають за зону (від кешуючих).

Відповідь DNS зазвичай містить таку інформацію:

• Запис заголовка - службову інформацію про запит.
• Запис запиту - повторює відправлений запит.
• Запис відповіді - власне, сам відповідь.
• Записи авторитетних серверів - інформацію про авторитетних серверах, що зберігають інформацію по поточному запиту.
• Додаткову інформацію - додаткові записи, наприклад адреси NS-серверів.

Вишенаписанное наочно підтверджується утилітою dig:

[Email protected]

: ~ # Dig ya.ru; << >> DiG 9.7.3 << >> ya.ru (розділ заголовка) ;; global options: + cmd ;; Got answer: ;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 53499 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: (розділ запиту); ya.ru. IN A ;; ANSWER SECTION: (розділ відповіді) ya.ru. 4813 IN A 87.250.250.203 ya.ru. 4813 IN A 87.250.251.3 ya.ru. 4813 IN A 93.158.134.3 ya.ru. 4813 IN A 93.158.134.203 ya.ru. 4813 IN A 213.180.204.3 ya.ru. 4813 IN A 77.88.21.3 ya.ru. 4813 IN A 87.250.250.3 ;; AUTHORITY SECTION: (авторитативні сервера) ya.ru. 4813 IN NS ns1.yandex.ru. ya.ru. 4813 IN NS ns5.yandex.ru. ;; ADDITIONAL SECTION: (додаткова інформація - адреси авторитативні name servers) ns5.yandex.ru. 345565 IN A 213.180.204.1 ns1.yandex.ru. 345565 IN A 213.180.193.1 ns1.yandex.ru. 3565 IN AAAA 2a02: 6b8 :: 1 ;; Query time: 7 msec ;; SERVER: 192.168.1.1 # 53 (192.168.1.1) ;; WHEN: Sat Jul 2 23:02:45 2011 ;; MSG SIZE rcvd: 238

Зворотне перетворення імен

DNS використовується в першу чергу для перетворення доменних імен в IP-адреси, але він також може виконувати зворотний процес, званий Зворотне перетворення імен або зворотним відображенням. Оскількі записи в прямій базі DNS структуровані ієрархічно по доменних іменах, DNS не може ефективно виконувати пошук по IP адресою в такій базі. Для зворотного перетворення в DNS використовується спеціальний домен in-addr.arpa. Ресурсні записи в даному домені в поле Name містять IP-адреси, в поле Type - PTR, а в поле Data - FQDN-имя відповідне даному IP.

На схемі представлена структура домена arpa. Думаю, що тут все досить наочно. Домен arpa. має 2 поддомена in-addr і ip6, що відповідають за IPv4 і IPv6 адреси відповідно. Домен in-addr.arpa. має від * .0.in-addr.arpa. до * .255.in-addr.arpa. піддоменів, кожен з яких так само має по 256 піддоменів.

З метою зменшення обсягу небажаної кореспонденції (спаму) багато поштові сервери можуть перевіряти наявність PTR запису для хоста, з якого відбувається відправка. В цьому випадку PTR запис для IP адреси повинна відповідати імені відправляє поштового сервера, яким він представляється в процесі SMTP сесії.

Наочно наведену схему можна уявити командами:

[ [Email protected] ~] # Dig www.ru ... ;; QUESTION SECTION:; www.ru IN A ;; ANSWER SECTION: www.ru 52119 IN A 194.87.0.50 ... [ [Email protected] ~] # Dig -x 194.87.0.50 ... ;; QUESTION SECTION:; 50.0.87.194.in-addr.arpa. IN PTR ;; ANSWER SECTION: 50.0.87.194.in-addr.arpa. 30385 IN PTR www.ru ....

При цьому, команду dig -x 194.87.0.50 правильніше буде представити як dig 50.0.87.194.in-addr.arpa., Тобто записи в піддоменів * .in-addr.arpa. представлені в так званої зворотної нотації (або reverse формі), тобто хосту з IP 194.87.0.50 буде відповідати PTR-запис, що має FQDN 50.0.87.194.in-addr.arpa., яка в свою чергу вказує на домен www.ru Хочеться відзначити, що найчастіше за зворотну зону і її редагування відповідає постачальник інтернету.

Як і обіцяв, описую ресурсну запис PTR в домені IN-ADDR.ARPA, відповідна наведеної вище записи А для машини www.ru. матиме такий вигляд:

50.0.87.194 IN PTR www.ru

Ім'я 50.0.87.194 не закінчується точкою і тому є відносним. Питання: відносним щодо чого? Ні в якому разі не щодо " www.ru ". Для того щоб цей запис був FQDN, домен за замовчуванням повинен називатися« IN-ADDR.ARPA. ». Цього можна домогтися або помістивши записи PTR в окремий файл, в якому доменне ім'я зони за замовчуванням - IN-ADDR.ARPA. ( заданий у файлі початкового завантаження демона named), або змінивши цей домен за допомогою директиви $ ORIGIN. Якщо домен за замовчуванням визначено як 0.87.194.IN-ADDR.ARPA., то запис можна змалювати таку картину:

80 IN PTR www.ru

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

У двох словах хотів би торкнутися питання реєстрації доменних імен.

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

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

Рівні доменів, для яких необхідна обов'язкова реєстрація особи, відповідальної за домен, такі:

• кореневої домен
• всі домени першого рівня (TLD)
• деякі домени другого рівня (наприклад, com.ru або co.uk)

Реєстратором для кореневого домена є організація ICANN . Щоб стати реєстратором доменів в зонах другого рівня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs ...), необхідно отримати акредитацію ICANN.

Правила реєстрації в міжнародних (gTLD - com., Org, і ін.) Доменах встановлюються ICANN. Правила реєстрації в національних (ccTLD - ru, us і ін.) Доменах встановлюються їх реєстраторами та / або органами влади відповідних країн, наприклад єдині правила для всіх реєстраторів в доменах .ru, і.рф задаються Координаційним центром національного домену мережі Інтернет. Для багатьох доменів (в тому числі і для ru) реєстратор не єдиний. При наявності декількох реєстраторів все вони повинні використовувати єдину (централізовану або розподілену) базу даних для виключення конфліктів і забезпечення унікальності доменного імені.

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

На завершення статті хочу відзначити так само про таке маркетинговому аспекті, що іноді домени другого рівня називають іменами доменів ПЕРШОГО рівня, тим самим «опускаючи» значення кореневого домена і приймаючи за кореневої домен - домени TLD.

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

резюме

Отже, в сьогоднішній статті я постарався якомога зрозуміліше описати роботи доменної системи імен. Сподіваюся, це у мене вийшло. Ми розглянули ієрархічну структуру бази даних DNS, а так само розглянули процеси взаємодії клієнтів і серверів DNS, а так же різновиди серверів DNS. У наступній статті я розгляну практичні питання установки і настройки DNS сервера BIND на Linux. Буду радий Вашим коментарям.

Що ще почитати:

man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0

man (3) gethostbyname: http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname&category=3

Linux Network Administrators Guide v2 Russian: завантажити .
RFC882, 1035, тисяча сто вісімдесят-три

джерело , джерело