Сервери, обслуговуючі кореневу зону (Root servers)

Кешуючий (cache) сервери

Цей тип серверів відрізняється від тих, що були розглянуті раніше, тим, що сервер даного типу не є авторитативним для будь-якої зони.

Сервери даного виду використовують для організації централізованого кешування відповідностей доменних імен і IP-адрес. Ідея організації кешуючого полягає в тому, щоб не шукати відповідність доменного імені та IP-адреси в мережі, а накопичувати їх у своєму локальному кеші і обслуговувати запити relover-ів, використовуючи дані кешу.

Кеш-сервер не підтримує описів зон і, відповідно, не посилає resolver'ам авторитативні відгуків:

MCBC\u003e nslookup

\u003e Set type \u003d any

\u003e www.w3.org

Server: udc.nwudc.lan

Address: 192.168.25.25

Non-authoritative answer:

www.w3.org internet address \u003d 193.51.208.69

www.w3.org internet address \u003d 128.30.52.31

www.w3.org internet address \u003d 128.30.52.45

www.w3.org internet address \u003d 128.30.52.46

www.w3.org internet address \u003d 128.30.52.47

www.w3.org internet address \u003d 128.30.52.54

w3.org nameserver \u003d ns3.w3.org

w3.org nameserver \u003d ns1.w3.org

w3.org nameserver \u003d ns2.w3.org

Вище наведено типовий відгук кешуючого на запит nslookup про адресу «www.w3.org». Якби сервер був авторитативним, то рядки «Non-authoritative answer» у відгуку не було.

Їх місце в отриманні відгуку на запит до системи доменних імен ключове. Саме до одного з кореневих серверів звертається локальний сервер доменних імен, якщо не знаходить в зоні своєї відповідальності або в своєму кеші відповідності між доменним ім'ям і IP-адресою.

Протокол DNS виконує дві основні функції. Він дозволяє клієнтським комп'ютерам запитувати DNS-сервер про IP-адресу або ім'я будь-якого хоста в мережі, а також дозволяє проводити обмін інформацією між базами даних серверів DNS. У цьому протоколі використовується стандартний формат типу «запит-відповідь», де клієнт посилає пакет запиту, і сервер відповідає або пакетом з інформацією, отриманою з бази даних, або повідомленням про помилку, в якому вказується причина відмови в обробці запиту. У своїй роботі цей протокол використовує порт 53 і добре відомі протоколи - TCP або UDP. Причому останнім часом UDP став більш поширеним методом транспортування пакетів по мережі Internet. Пакет DNS складається з п'яти полів: заголовка, питання, відповіді, повноважень і поля додаткової інформації. На малюнку 5.7 показана загальна структура пакета DNS.

Рис. 5.7 Опис пакета протоколу DNS

поле заголовка

В поле заголовка міститься інформація про пакет і його призначення. У ньому дається загальний опис пакета (пакет запиту або пакет відповіді) і вказується кількість даних, що містяться в кожному полі даних пакета. Опис заголовка наводиться в таблиці 5.1.

Біти ID є унікальним 16-бітових ідентифікаційним номером пакета запиту. Пакет відповіді, що формується сервером, також використовує цей ідентифікаційний номер, щоб клієнт міг зіставити відповідь сервера зі своїм запитом. Біт QR позначає тип пакета (пакет запиту - 0, пакет відповіді - 1). Поле OPCODE визначає тип запиту - стандартний (0), зворотний (1) або запит про статус сервера (2).

Таблиця 5.1. Поле заголовка DNS-пакета

біт	опис	біт	опис
0-15	ID		RA
	QR	25-27	Z
17-20	OPCODE	28-31	RCODE
	AA	32-47	QDCOUNT
	TC	48-63	ANCOUNT
	RD	64-79	NSCOUNT
		80-95	ARCOUNT

Наступні чотири біта визначають різні параметри пакета. Біт AA встановлюється, коли відповідь є авторитетним (дані надходять безпосередньо від DNS-сервера, відповідального за зону). Неавторитетні відповіді можуть надходити від серверів DNS, в кеші яких збереглася інформація про вихідні записах від попередніх запитів. Ця інформація вважається неавторитетною, так як є ймовірність, що з моменту останнього звернення до сервера інформація була змінена. Біт TC встановлюється, коли потрібно урізати дані в пакеті до виду, зручного для передачі по мережі. Таке цілком можливо при використанні протоколу UDP, згідно з яким розмір пакета не повинен перевищувати 512 байт. Біт RD включається, коли клієнт бажає рекурсивно запитувати DNS-сервер на постійній основі. Якщо цей біт встановлений, то DNS-сервер буде запитувати інші DNS-сервери, поки не отримає відповідь. Якщо цей біт не встановлений, то DNS-сервер буде повертати на запит будь-яку інформацію, яка у нього є. Біт RA встановлюється, щоб повідомити клієнта про можливості рекурсивного запиту на даний сервер. Біти Z в даний час не використовуються і зарезервовані на майбутнє.

Біти RCODE використовуються тільки в пакетах відповідей. Вони відображають стан відповіді - без помилок (0), помилки в пакеті запиту (1), внутрішні помилки не дали можливості сервера обробити запит (2), ім'я, вказане в запиті, не існує (3), даний тип запиту не підтримується сервером ( 4) і сервер відмовився обробити запит (5).

Решта чотири параметри заголовка є 16-бітові числа і використовуються в якості лічильників. З їх допомогою ведеться облік кількості вихідних записів, що повертаються в пакеті. QDCOUNT відображає кількість запитів (в пакет може включатися більше одного запиту). ANCOUNT - кількість вихідних записів, включених у відповідь. NSCOUNT позначає число вихідних записів про авторитетних серверах імен, а ARCOUNT - число записів в поле додаткової інформації.

поле питання

Поле питання містить запити, відповіді на які клієнт бажає отримати від DNS-сервера. В одному пакеті DNS може мати декілька запитів. Кількість запитів у пакеті визначається параметром QDCOUNT з поля заголовка. Поле питання складається з трьох частин: переліку перетворюються доменних імен; поля типів записів, які клієнт бажає отримати у відповіді, і параметра класу запиту. Список перетворюються доменних імен являє собою список імен, для яких клієнт бажає отримати IP-адреси. Для формування списку імен використовується спеціальний формат. Перед кожним ім'ям ставиться однобайтное значення, яке визначає довжину імені. Кінець списку позначається ім'ям з нульовою довжиною. Після текстової частини слід двубайтная запис QTYPE. У ній визначається, в якому вигляді клієнт бажає приймати інформацію про наявних доменах. Ці значення повністю відповідають типам вихідних записів в DNS. Наприклад, для того щоб знайти поштовий сервер для певного домену, вам слід скористатися типом записи МХ. І, нарешті, останній параметр в поле питання - QCLASS. Він визначає клас запиту, який в нашому випадку для мережі Internet завжди буде IN.

Поля відповіді, повноважень і додаткової інформації

Наступні три поля пакета DNS мають один і той же формат. Кожне з них може повертати дані в форматі вихідного запису бази даних DNS. У відповідях містяться вихідні записи бази DNS, доступні на сервері на момент запиту клієнта. Якщо біт заголовка АА не встановлено, то в розділі авторитетних серверів будуть вказані DNS-сервери, до яких клієнт може звертатися за авторитетними відповідями. Отже, авторитетні відповіді надходять від DNS-серверів, які відповідальні за зони, що містять запитувана ім'я хоста. Всі інші відповіді вважаються неавторитетна, тому що міститься в них інформація береться з кешу DNS-сервера і може бути застарілою. В поле додаткової інформації подаються всі вихідні записи, які сприймаються DNS-сервером як такі, що ставлення до цього запиту.

Наприклад, якщо запросити інформацію про МХ-записах домену, то в поле відповіді буде отримана інформація про МХ-записах, а в поле додаткової інформації - записи А для серверів, зазначених в поле відповіді. Таким чином, за допомогою одного DNS-запиту можна дізнатися і ім'я, і \u200b\u200bIP-адресу поштового сервера для домена.

Формат представлення вихідної записи в пакеті DNS показаний в таблиці 5.2.

Таблиця 5.2. Формати полів відповіді, повноважень і додаткової інформації

В поле відповіді значення RDATA відповідають результатам обробки запиту. Записи МХ подаються не в текстовому форматі. Разом з ім'ям поштового сервера в них вноситься значення пріоритету.

Premium DNS - пакет послуг, за допомогою якого можна більш гнучко управляти зоною домена, а також переглядати історію змін DNS-записів.

Вся інформація про домени, для яких підключений Premium DNS, Дублюється на наші DNS-сервери і зберігається в надійних дата-центрах. «Страхуючі» сервери об'єднуються в мережу Anycast. Це забезпечує їх безперебійну роботу. Якщо один з серверів відмовляє, інші продовжують роботу і надають безперебійний uptime ваших сайтів і сервісів на домені.

Якщо для вашого домену прописані хостингові DNS-сервери (ns1.hosting..hosting..

Пакет послуг Premium DNS дає можливість:

створювати шаблони DNS-зон;

експортувати DNS-зони;

імпортувати DNS-зони;

відкотити будь-яка небажана зміна DNS-записів і відновити настройки зони, на яких сайт функціонує без помилки;

використовувати послугу для захисту від кібератак;

скоротити час відновлення зони після будь-якої операції до 10 хвилин (На стандартних умовах оновлення займає не менше 1 години);

підвищити відмовостійкість системи і забезпечити безперебійну роботу інтернет-ресурсів клієнтів сайт.

Кому корисний Premium DNS?

Пакет послуг підійде роздрібним клієнтам з великою кількістю доменів на одному акаунті, а також партнерам, які займаються реселлінга послуг.

Як замовити Premium DNS?

Готово! Ви замовили послугу Premium DNS.

Управління послугою Premium DNS

Як застосувати створений шаблон зони?

Перейдіть на вкладку «Шаблони зон» і навпаки необхідного шаблону натисніть застосувати шаблон:

Готово! Створений шаблон зони застосований.

Експорт та імпорт зони домену

Перейдіть на вкладку «Управління зоною». Для імпорту або експорту зони домену натисніть Експорт / Імпорт і виберіть необхідну дію:

Експорт зони проводиться в форматі BIND. Імпортувати зону можливо також тільки з файлу з форматом BIND.

Готово! Шаблон експортований / імпортовано.

Як змінити тариф Premium DNS?

Прямий зміни тарифу Premium DNS «для домену» на Premium DNS «для аккаунта» немає.

У цьому розділі ми зіткнулися з поняттями DNS-запиту і DNS-відповіді. Запит і відповідь є єдині два типи повідомлень, які використовуються протоколом DNS. Формати цих повідомлень збігаються і представлені на рис. 2.17. Нижче наведено опис структури DNS-повідомлення.

□ Перші 12 байт складають заголовну секцію, що складається з декількох полів. Перше поле являє собою 16-розрядне число, що ідентифікує запит. Ідентифікатор запиту копіюється в відповідь було надіслане, що дозволяє клієнту зіставляти відповіді з запитами. Поле прапорів включає однорозрядних прапор «запит / відповідь» і визначає, чи є повідомлення запитом (0) або відповіддю (1). Однорозрядних прапор повноважності встановлюється для відповідного повідомлення в разі, якщо сервер імен є повноважним для запитуваної імені.

Однорозрядних прапор перевагу рекурсії встановлюється в разі, коли клієнту (хосту або сервера імен) необхідно дати вказівку сервера імен застосувати рекурсивний запит за відсутності IP-адреси. Однорозрядних прапор доступності рекурсії встановлюється у відповідному повідомленні, якщо сервер імен підтримує рекурсивний механізм запитів. У заголовку також містяться чотири секції для «типів» даних.

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

□ Секція відповідей присутній в відповідних повідомленнях і містить необхідні ресурсні записи. Кожна RR-запис включає поля Туре з одним зі значень A, NS, CNAME або MX, Value і TTL. Оскільки імені хоста можна порівнювати кілька IP-адрес (наприклад, через дублювання web-серверів, згадуваного в цьому розділі), секція відповідей також може містити кілька записів.

□ Секція повноважності включає в себе записи про інших повноважних серверах.

□ Додаткова секція містить інші «корисні» записи. Наприклад, в поле відповідей для запиту на запис типу MX може перебувати запис, що зберігає канонічне ім'я поштового сервера, а в додаткову секцію поміщена запис типу А з IP-адресою поштового сервера.

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

Протокол DNS виконує дві основні функції. Він дозволяє клієнтським комп'ютерам запитувати DNS-сервер про IP-адресу або ім'я будь-якого хоста в мережі, а також дозволяє проводити обмін інформацією між базами даних серверів DNS. У цьому протоколі використовується стандартний формат типу "запит-відповідь", де клієнт посилає пакет запиту, і сервер відповідає або пакетом з інформацією, отриманою з бази даних, або повідомленням про помилку, в якому вказується причина відмови в обробці запиту. У своїй роботі цей протокол використовує порт 53 і добре відомі протоколи - TCP або UDP. Причому останнім часом UDP став більш поширеним методом транспортування пакетів по мережі Internet. Пакет DNS складається з п'яти полів: заголовка, питання, відповіді, повноважень і поля додаткової інформації. На рис. 4.5 показана загальна структура пакета DNS.

Рис. 4.5.

поле заголовка

В поле заголовка міститься інформація про пакет і його призначення. У ньому дається загальний опис пакета (пакет запиту або пакет відповіді) і вказується кількість даних, що містяться в кожному полі даних пакета. опис заголовка наводиться в табл. 4.3.

Таблиця 4.3. Поле заголовка DNS-пакета

біт	опис
0-15	ID
16	QR
17-20	OPCODE
21	AA
22	TC
23	RD
24	RA
25-27	Z
28-31	RCODE
32-47	QDCOUNT
48-63	ANCOUNT
64-79	NSCOUNT
80-95	ARCOUNT

Біти ID є унікальним 16-бітових ідентифікаційним номером пакета запиту. Пакет відповіді, що формується сервером, також використовує цей ідентифікаційний номер, щоб клієнт міг зіставити відповідь сервера зі своїм запитом. Біт QR позначає тип пакета (пакет запиту - 0, пакет відповіді - 1). поле OPCODE визначає тип запиту - стандартний (0), зворотний (1) або запит про статус сервера (2).

Наступні чотири біта визначають різні параметри пакета. Біт AA встановлюється, коли відповідь є авторитетним (дані надходять безпосередньо від DNS-сервера, відповідального за зону). Неавторитетні відповіді можуть надходити від серверів DNS, в кеші яких збереглася інформація про вихідні записах від попередніх запитів. Ця інформація вважається неавторитетною, так як є ймовірність, що з моменту останнього звернення до сервера інформація була змінена. Біт TC встановлюється, коли потрібно урізати дані в пакеті до виду, зручного для передачі по мережі. Таке цілком можливо при використанні протоколу UDP, згідно з яким розмір пакета не повинен перевищувати 512 байт. Біт RD включається, коли клієнт бажає рекурсивно запитувати DNS-сервер на постійній основі. Якщо цей біт встановлений, то DNS-сервер буде запитувати інші DNS-сервери, поки не отримає відповідь. Якщо цей біт не встановлений, то DNS-сервер буде повертати на запит будь-яку інформацію, яка у нього є. Біт RA встановлюється, щоб повідомити клієнта про можливості рекурсивного запиту на даний сервер. Біти Z в даний час не використовуються і зарезервовані на майбутнє.

Біти RCODE використовуються тільки в пакетах відповідей. Вони відображають стан відповіді - без помилок (0), помилки в пакеті запиту (1), внутрішні помилки не дали можливості сервера обробити запит (2), ім'я, вказане в запиті, не існує (3), даний тип запиту не підтримується сервером ( 4) і сервер відмовився обробити запит (5).

Решта чотири параметри заголовка є 16-бітові числа і використовуються в якості лічильників. З їх допомогою ведеться облік кількості вихідних записів, що повертаються в пакеті. QDCOUNT відображає кількість запитів (в пакет може включатися більше одного запиту). ANCOUNT - кількість вихідних записів, включених у відповідь. NSCOUNT позначає число вихідних записів про авторитетних серверах імен, а ARCOUNT - число записів в поле додаткової інформації.

поле питання

Поле питання містить запити, відповіді на які клієнт бажає отримати від DNS-сервера. В одному пакеті DNS може мати декілька запитів. Кількість запитів у пакеті визначається параметром QDCOUNT з поля заголовка. Поле питання складається з трьох частин: переліку перетворюються доменних імен; поля типів записів, які клієнт бажає отримати у відповіді, і параметра класу запиту. Список перетворюються доменних імен являє собою список імен, для яких клієнт бажає отримати IP-адреси. Для формування списку імен використовується спеціальний формат. Перед кожним ім'ям ставиться однобайтное значення, яке визначає довжину імені. Кінець списку позначається ім'ям з нульовою довжиною. Після текстової частини слід двубайтная запис QTYPE. У ній визначається, в якому вигляді клієнт бажає приймати інформацію про наявних доменах. Ці значення повністю відповідають типам вихідних записів в DNS. Наприклад, для того щоб знайти поштовий сервер для певного домену, вам слід скористатися типом записи МХ. І, нарешті, останній параметр в поле питання - QCLASS. Він визначає клас запиту, який в нашому випадку для мережі Internet завжди буде IN.