Звертаючись до іншого вузла (наприклад, відкриваючи сторінку в браузері йде звернення до веб-сервера, а під час відкриття поштової програми— звернення до поштового сервера), користувач може вказати адресу вузла прямо чи опосередковано, що, своєю чергою, змушує вузол користувача передавати пакет інший вузол. Проте вузли не можуть передавати пакети із зазначенням імені вузла-отримувача, тому в більшості мереж для перетворення імен вузлів у їх IP-адреси використовується протокол DNS.

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

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

Записи DNS бувають різних типіві містять різну інформацію. Основні записи, які слід згадати, відображені в таблиці 1.

Тип	Розшифровка	Опис
A	Address	Адресний запис, відповідність між ім'ям та IP-адресою
CNAME	Canonical name	Канонічне ім'я для псевдоніма (однорівнева переадресація)
NS	Authoritative name server	Адреса вузла, який відповідає за доменну зону. Критично важлива для функціонування самої системи доменних імен
PTR	Domain name pointer	Реалізує механізм переадресації
SOA	Start of authority	Вказівка ​​на авторитетність інформації, що використовується для вказівки на нову зону

Табл. 1. Основні ресурсні записи DNS

Aзапис містить відповідність IP-адреси доменному імені. Використовується при дозволі імені вузла, наприклад, коли браузеру потрібно відкрити веб-сторінку (доменне ім'я). У запиті вказується ім'я вузла, а DNS-сервер у відповіді надсилає IP-адресу цього вузла, взяту з Aзапису. Запис містить IP-адресу.

CNAMEзаписи дозволяють задати «псевдонім» або «канонічне ім'я» для хоста, щоб прив'язати його не до конкретної IP-адреси, а послатися на інший хост. Наприклад, якщо вузол має кілька доменних імен, достатньо вказати один Aзапис та посилатися на нього. У записі міститься доменне ім'я.

NSзаписи служать для вказівки NS-серверів, що обслуговують цю зону та зони наступного рівня. Запис містить адресу відповідального DNS сервера.

PTRзапис пов'язує IP хоста з його канонічним ім'ям. Цей запис важливий при надсиланні пошти. З метою зменшення обсягу спаму багато серверів-отримувачів електронної поштиможуть перевіряти наявність PTR запису для хоста, з якого відбувається надсилання. В цьому випадку PTR записдля IP адреси має відповідати імені відправника поштового сервераяким він представляється в процесі SMTP сесії. Найчастіше, провайдери інтернету створюють для IP-адрес своїх абонентів автоматично згенеровані за певним шаблоном PTR-запису. Тому при налаштуванні на одній із таких адрес поштового сервера поряд з реєстрацією домену у реєстратора доменних імен потрібно змінювати PTR запис на DNS сервері провайдера.

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

Що такеDNS

DNS (domain name system) – це система, що забезпечує роботу звичних нам доменних імен сайтів. Зв'язок між пристроями в мережі Інтернет здійснюється за адресами IP, наприклад: "192.64.147.209". Однак запам'ятати IP адреси складно, тому були придумані зручні для людини доменні імена, наприклад: "google.com".

Комп'ютер/сервер не зберігає таблицю відповідності доменів та їх IP-адрес. Точніше, не зберігає всю таблицю, а тимчасово запам'ятовує дані для доменів, що часто використовуються. Коли в браузері вводиться домен сайту, комп'ютер автоматично дізнається його IP адресу, і надсилає запит. Цей процес називається "дозвіл адреси домену" (domain resolving).

Розберемося, із чого складається система DNS і як вона працює.

Як працюєDNS

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

Ієрархічна структура доменних імен:

• Доменні зони верхнього рівня (першого рівня) – наприклад: "ru", "com", або "org". Вони включають всі доменні імена, що входять в цю зону. До будь-якої доменної зони може входити необмежену кількість доменів.
• Доменні імена (доменні зони другого рівня)- Наприклад: "google.com" або "yandex.ru". Т.к. система доменних імен є ієрархічною, то "yandex.ru" можна також назвати піддоменом вищої зони "ru". Тому правильніше вказувати саме рівень домену. Однак на практиці доменну зону будь-якого рівня називають просто «доменом».
• Піддомени (доменні зони третього рівня)- Наприклад: "api.google.com" або "mail.yandex.ru". Можуть бути доменні зони 4, 5 рівнів тощо.

Зверніть увагу, що "www.gооgle.com" та "google.com" - це, фактично, різні домени. Потрібно не забувати вказувати А-записи для кожного з них.

DNS сервер або NS (name server) сервер- Підтримує (обслуговує) доменні зони, які йому делеговані. Він безпосередньо зберігає дані про ресурсні записи для зони. Наприклад, сервер, на якому знаходиться сайт "example.ru", має IP адресу "1.1.1.1". DNS сервер відповідає на всі запити щодо цих доменних зон. Якщо йому надходить запит про домен, який йому не делегований, він запитує відповідь в інших DNS серверів.

DNS записи (ресурсні записи)– це набір записів про доменну зону на NS сервері, які зберігають дані необхідні для роботи DNS. На підставі даних у цих записах, сервер DNS відповідає на запити по домену. Список записів та їх значення ви можете знайти нижче.

Кореневий сервер DNS(на Наразіїх 13 у всьому світі) зберігають дані про те, які сервери DNS обслуговують зони верхнього рівня.

DNS сервер доменних зон верхнього рівня- зберігають інформацію, які NS сервери обслуговують той чи інший домен.

Для того, щоб дізнатися IP адресу, домену комп'ютер/сервер звертається до DNS-сервера, який вказаний у нього в мережевих налаштуваннях. Зазвичай це DNS сервер Інтернет провайдера. DNS сервер перевіряє делегований домен йому чи ні. Якщо так, то одразу відповідає на запит. Якщо ні, то запитує інформацію про DNS сервер, який обслуговує цей домен, у кореневого сервера, а потім у сервера доменних зон верхнього рівня. Після цього безпосередньо робить запит на NS сервер, що обслуговує цей домен, і транслює відповідь вашому комп'ютеру / серверу.

Кешування данихвикористовується усім пристроях (комп'ютерах, північах, DNS серверах). Тобто, вони запам'ятовують відповіді на останні запити, що прийшли до них. І коли приходить аналогічний запит, вони просто відповідають те саме, що і в попередній раз. Наприклад, якщо ви у браузері відкрили сайт google.com вперше після включення, то комп'ютер зробить DNS запит, а при наступних запитах братиме дані, які йому були надіслані DNS сервером вперше. Таким чином, для популярних запитівне треба щоразу проходити весь ланцюжок і генерувати запити до NS серверів. Це значно знижує навантаження на них і збільшує швидкість роботи. Однак, як результат, оновлення даних у системі DNSвідбувається не одразу. При зміні IP адреси домену, інформація про це буде розходитися через Інтернет від 1 до 24 годин.

Реєстрація/виділення доменів

У кожної доменної зонипершого рівня є своя організація, яка встановлює правила виділення доменів та забезпечує роботу цієї зони. Наприклад, для доменних зон RU, SU та РФ – це Координаційний центр національного доменумережі Інтернет https://cctld.ru. Ці організації встановлюють правила роботи та технічні вимогидо реєстраторів доменів.

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

Адміністратор домену (власник)- Особа, якій безпосередньо належать права на доменне ім'я. Він може керувати доменом, від нього реєстратор приймає заявки на внесення змін.

Делегування домену– вказівка ​​для нього серверів DNS, які будуть його обслуговувати.

ОсновніDNS запису

Існують такі основні DNS (ресурсні) записи:

А – містить інформацію про IPv4 адресу хоста (сервера) для домену. Наприклад, 1.1.1.1.

ААА – містить інформацію про IPv6 адресу хоста (сервера) для домену. Наприклад, 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d.

MX – містить дані про поштовий сервер домену. При цьому вказується саме ім'я сервера пошти, наприклад mail.example.com. Т.к. У домену може бути кілька поштових серверів, то для кожного з них вказує пріоритет. Пріоритет визначається числом від 0 до 65535. При цьому «0» - це найвищий пріоритет. Прийнято за промовчанням для першого поштового сервера вказувати пріоритет «10».

TXT – додаткова інформація про домен як довільний текст. Максимальна довжина 255 символів.

SRV – містить інформацію про ім'я хоста та номер порту, для певних служб / протоколів відповідно до RFC 2782 http://www.rfc-editor.org/rfc/rfc2782.txt . Містить такі поля:

• _Service._Proto.Name (Приклад: _jabber._tcp.jabber), де:
  • Service: назва служби (приклад: ldap, kerberos, gc та інші).
  • Proto: протокол, з якого клієнти можуть підключитися до цієї службі (приклад: tcp, udp).
  • Name: ім'я домену, в якому розміщено цю службу.
• Пріоритет – також як для MX запису вказує пріоритет для даного сервера. Задається числом від 0 до 65535. При цьому "0" - це найвищий пріоритет.
• Вага - Відносна вага для розподілу навантаження між серверами з однаковим пріоритетом. Задається цілим числом.
• Порт – це номер порту, на якому знаходиться служба на даному сервері.
• Призначення – доменне ім'я сервера, що надає цю службу.

NS – ім'я DNS сервера, який підтримує цей домен.

CNAME (канонічне ім'я хоста / canonical name) – використовується для перенаправлення на інше доменне ім'я. Наприклад, ім'я сервера змінилося з example.com на new.com. У такому разі в полі «Alies» для запис cnameтреба вказати – example.com, а в полі «Canonical name» – new.com. Таким чином, всі запити на example.com будуть автоматично перенаправлені на new.com.

SOA – базовий запис про домен. У ній зберігається саме ім'я домену та час життя даних про домен - TTL. TTL (time-to-live) визначає, який період часу DNS сервер отримавши інформацію про зону, буде зберігати її у себе в пам'яті (кешувати). Рекомендоване значення 86 400 – 1 день. Значення вказується за секунди.

Протокол 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.

Відображення адрес в імена

IP адреса записується в десятково-точкової нотації. Для пошуку доменних імен за адресами IP використовується домен in-addr.arpa. Його піддоменами є домени з простими іменами від 0 до 255, що відповідають старшому октету IP-адреси. Їхніми піддоменами є домени з простими іменами від 0 до 255, що відповідають другому октету IP адреси і т.д. до 4-го октету. Таким чином, IP адреса виявляється записаним у доменному імені у зворотному порядку. Наприклад, адреса 195.161.72.28 відповідає доменне ім'я 28.72.161.195.in-addr.arpa. (та значення PTR – deol.deol.ru). Зворотній записнеобхідна для легшого делегування зон відповідно до виділення IP адрес.

Зони верхнього рівня домену in-addr.arpa. делеговані IANA регіональним реєстраторам (RIR, Regional Internet Registrator) разом із блоками IP-адрес.

RIPE для делегування підзони вимагає від LIR внесення інформації до БД RIPE. Якщо ви представляєте LIR, то мали закінчити спеціальні курси, а якщо ні, то прав на внесення інформації в БД RIPE вам не дадуть і доведеться просити свій LIR. У БД мають бути як мережа (whois [email protected]), так і зона (whois [email protected])

Відображення адрес в імена може бути обов'язковим для деяких сервісів Інтернет: немає відображення – немає обслуговування.

Записи про ресурси (RR, Resource Records)

Записи ресурсів можуть бути представлені у текстовому форматі у файлі даних зони та у двійковому форматі під час обміну повідомленнями протоколу DNS. Текстовий форматзони може відрізнятися для різних реалізацій сервера DNS, тут описується формат, згаданий у стандарті (RFC 1035) і використовується в BIND 4/8/9. Файл зони повинен містити записи лише одного класу.

Кожен запис розташовано на окремому рядку. Порожні рядкиігноруються. Кордони рядків не розпізнаються всередині круглих дужок та текстових літералів у лапках. Розділювачами полів є прогалини та табуляції. Коментарі починаються з символу крапки з комою в будь-якому місці рядка і продовжуються до кінця рядка. Крім записів ресурсів, файл зони може містити директиви $ORIGIN, $INCLUDE і $TTL (починаючи з BIND 8.2). Символ "@" використовується для позначення поточного суфікса за промовчанням для відносних доменних імен. Зворотна коса риса маскує спеціальний зміст наступного символу. Можливе завдання довільних октетів у вигляді вісімкових чисел(\012). Регістр букв не враховується під час пошуку, але повертається у відповіді.

Директива $ORIGIN визначає поточний суфікс за промовчанням для відносних доменних імен. Директива $INCLUDE вставляє вказаний файлфайл зони і задає (тільки для записів з вставляемого файлу) поточний суфікс для відносних доменних імен (суфікс може бути опущений). У старих версіях BIND та його похідних (наприклад, in.named в Solaris 2.5) зміна суфікса не спрацьовує (хоча й повідомлення про помилку не видається!) і доводиться "обігати" директиву $INCLUDE директивами зміни $ORIGIN та її відновлення. Директива $TTL задає стандартний TTL (RFC 2308).

Запис ресурсу складається з доменного імені (якщо опущено, то мається на увазі значення з попереднього запису ресурсу), імені класу (може бути опущено та братися з попереднього запису), TTL (число секунд, може бути опущено та братися з директиви $TTL для BIND 8.2 та новіше або з поля MINIMUMTTL в SOA для старих версій; рекомендоване значення – одна доба; розумне – від 1 години до тижня; У нових версіях (BIND ?) часи можуть задаватися як у секундах, так і хвилинах (суфікс m), годинниках (суфікс h), днях (суфікс d), тижнях (суфікс w). Тільки імена вузлів зобов'язані відповідати синтаксису доменних імен (літери, цифри та мінус), інші (наприклад, перша мітка поштової адресиу записі SOA) можуть складатися з довільних символів ASCII.

Класи записів (у тяжкій еволюційній боротьбі вижив тільки IN), у дужках – код для повідомлень протоколу DNS:

• IN (1) – Інтернет
• CS (2) – CSNET
• CH (3) – CHAOS
• HS (4) – Hesiod

Типи записів, у дужках – код для повідомлень протоколу DNS:

BIND версія? дозволяє додатково використовувати директиву $GENERATE для створення послідовності RR, які відрізняються лише параметром:

$GENERATE інтервал ліва-частина тип-запису права-частина

Інтервал чисел задається або як початок-кінець, або як початок-кінець/крок. За замовчуванням крок дорівнює 1. Ліва частиназадає правило формування доменних імен для послідовності записів, у яких індекс пробігає від початку до кінця з кроком крок. Права частиназадає правило формування даних запису (поки що дозволені лише типи PTR, CNAME, DNAME, A, AAAA і NS). У правилах одинокий символ $ замінюється поточним значенням індексу. Значення індексу може бути модифіковано завданням зміщення (віднімається з індексу), ширини поля (використовується для форматування результату) та системи числення (d, o, x, X) фігурних дужкахчерез кому. Якщо вийшло відносне ім'я, воно доповнюється поточним суфіксом. Використовується в основному для автоматичної генераціїзворотних зон:

$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-127 $CNAME $.0

перетворюється на

1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA
2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA
...
127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA

Протокол DNS

Запити та відповіді DNS зазвичай використовують протокол UDP (порт 53, domain), проте можуть використовувати протокол TCP (порт 53, domain). Кожне повідомлення повністю міститься в один UDP пакет, отже не може бути більше 64 KB. Насправді, багато продажів мають обмеження на розмір нефрагментованого UDP пакета в 576 байт. У такому пакеті міститься інформація про 10 записів типу NS у загальному випадку. Доменні імена кореневих серверів Інтернет були поміщені в один домен, що дозволило запакувати інформацію за допомогою посилань (див. нижче) про 13 серверів. Якщо відповідь не міститься в один фрагмент UDP, то в заголовку встановлюється біт TC (truncated), що призводить до повторного запиту з використанням протоколу TCP. При використанні протоколу TCP до кожного повідомлення додається префікс (2 байти), що містить довжину повідомлення без урахування префікса. Першим передається лівий біт (нульовий) – старший за значенням.

Формат запитів та відповідей однаковий ( докладніше див. RFC 1035)

Розширення протоколу TSIG

RFC 2845 розширює протокол DNSможливістю перевірки цілісності запитів та відповідей (QUERY), передачу зон, а також аутентифікацію динамічних змін (UPDATE, RFC 2136) за допомогою криптографічно стійких контрольних сум- TSIG (transaction signatures). При генерації хешу використовується алгоритм HMAC-MD5 і секрет, що розділяється між двома учасниками ( симетричний ключ). Механізм розподілу ключів не визначається. Учасники транзакції можуть розділяти кілька ключів, тому для ідентифікації конкретного ключа використовується його ім'я домену. Для запобігання атакам повторного відтвореннязапис містить час підпису (потрібна синхронізація часу за допомогою, наприклад, NTP). Відповідаючи на захищений запит, сервер посилає відповідь, захищений тим самим алгоритмом і ключем. Як ключі рекомендується використовувати випадкові послідовності довжиною не менше 128 біт.

Даний механізм вимагає меншого навантаження на процесор та менших витрат на створення інфраструктури при невеликій кількості вузлів порівняно з DNSSEC з його механізмами асиметричного шифрування та публічних ключів(RFC 2535, RFC 2137). З іншого боку, DNSSEC дозволяє легко масштабувати встановлену інфраструктуру розподілу ключів та забезпечувати цифровий підпис(TSIG, незважаючи на назву, не дозволяє проводити підтвердження авторства запитів через симетричність ключа).

RFC 2845 вводить новий тип запису TSIG (250) та кілька нових кодів відповіді. Запис типу TSIG є віртуальним, тобто. обчислюється під час транзакції, не міститься у файлі даних зони та не кешується. Запис додається до розділу додаткових даних; включає ім'я ключа, що розділяється, клас (ANY), TTL (0), ім'я алгоритму (зараз завжди HMAC-MD5), час підпису, інтервал відхилення часу, хеш, ідентифікатор вихідного повідомлення (використовується при ретрансляції динамічних змін), код помилки, додатковий дані про помилку (наприклад, розбіжність годинників учасників). Для генерації хешу використовують вихідне повідомлення, ім'я ключа, клас, TTL, ім'я алгоритму, час підпису, інтервал відхилення часу. При генерації хеша відповіді вихідні дані включається також хеш запиту.

Динамічні зміни зони

RFC 2136 розширює протокол DNS можливістю динамічної зміни вмісту зони на вимогу клієнта. Це позбавляє необхідності при частих змінах (наприклад, робота DHCP) редагувати текстовий файлз описом зони та перезапускати сервер. За допомогою даного розширенняможна одним пакетом внести кілька змін до зони, керованої цим первинним уповноваженим сервером (всі доменні імена мають бути всередині зони):

• додати запис ресурсу (RR) до набору записів ресурсів (RRset); записи типу SOA та CNAME не додаються, а заміщаються; якщо SOA не було або її серійний номер був більшим, то додавання ігнорується; спроба замінити нормальний набір записів на CNAME або CNAME на нормальний набір записів ігнорується; спроба додати дублюючий запис ігнорується
• видалити запис ресурсу (RR) із заданим значенням із набору записів ресурсів (RRset); не видаляються останній запис NS та SOA самої зони; спроба видалити неіснуючий запис ігнорується
• видалити набір записів ресурсів (RRset); не видаляються записи NS та SOA самої зони; спроба видалити неіснуючий набір ігнорується
• видалити всі набори ресурсів, що належать до вказаного доменного імені; не видаляються записи NS та SOA самої зони; спроба видалити неіснуючий набір ігнорується

Набір змін може бути випереджений набором умов наступних типів (всі доменні імена повинні бути всередині зони):

• вказане доменне ім'я має хоча б один запис ресурсу вказаного типу
• вказане доменне ім'я має записи ресурсів зазначеного типу з заданими значеннями(значення TTL не враховується, при порівнянні імен прописні та малі літерине розрізняються, шаблони не обробляються, синоніми (CNAME) не обробляються)
• вказане доменне ім'я не має жодного запису ресурсу зазначеного типу
• вказане доменне ім'я має хоча б один запис ресурсу
• вказане доменне ім'я не має жодного запису ресурсу

есь пакет умов та змін є атомарним, тобто. обробляється як єдине неподільне ціле (як транзакція до СУБД). У цьому сервер зобов'язаний записати зміни на диск до відповіді клієнту. bind тимчасово записує зміни до журналу та зливає його з файлом зони пізніше. Якщо зміни не торкнулися SOA, сервер повинен збільшити серійний номер автоматично. Метод стандартом не задається. Якщо автозбільшення серійного номеравиконується із затримкою, але вона не повинна бути більше 300 секунд або 1/3 від часу оновлення зони.

RFC 2136 вводить новий клас NONE (254) та кілька нових кодів відповіді. Формат запитів та відповідей збігається з форматом звичайних запитів та відповідей, але має код запиту – UPDATE (5). Секція запиту містить ім'я змінної зони (рівно один запис ресурсу типу SOA), секція відповіді – набір умов, секція посилань на уповноважені сервери – записи, що додаються або видаляються, секція додаткової інформації – сполучні записи доменних імен поза зоною (може ігноруватися сервером).

Клієнт може отримати список потенційних серверів із записів SOA, NS або зовнішніми засобами.

Сервер може перевіряти право клієнта на зміну зони на його IP адресу (не рекомендується) або за допомогою механізму TSIG.

Вторинний уповноважений сервер, який отримав запит на динамічна зміназони може перенаправити його первинному серверу від свого імені (змінивши ідентифікатор запиту) і отримавши відповідь повернути його клієнту. Той у свою чергу може переправити його далі і т.д. Список серверів, що використовуються, збігається зі списком серверів, до яких видаються запити на передачу зони. Якщо клієнт використовував для запиту TCP (рекомендується, якщо є обробка результату), то вторинний сервер повинен використовуватиме перенаправлення запиту також TCP.

Забезпечення правильного порядку застосування змін (так щоб “старі зміни, що затрималися в дорозі”, не перекривали новіші) нетривіальним завданняму середовищі TCP/IP, особливо за наявності кількох запитів клієнтів і кількох перенаправляющих вторинних серверів. Відповідь сервера також може затриматись або загубитися. Автори RFC рекомендують користуватися "маркерними" записами ресурсів для забезпечення синхронізації (такий маркер може, наприклад, містити час видачі запиту).

DNS клієнт (resolver)

Клієнти DNS зазвичай реалізуються у вигляді бібліотеки підпрограм, що приєднуються до кожної програми (статично або динамічно), яка потребує сервісу доменних імен. Простий (stub) клієнт звертається до зазначеного при налаштування DNSсерверу (серверам), інтерпретує відповідь і повертає результат програмі, що запросила. Реалізація клієнта в Solaris (Solaris 2.5.1 і молодше відповідає BIND 4.8.3; із латками – BIND 4.9.3; Solaris 2.6, 7 та 8 – BIND 4.9.4-P1) та Linux (клієнт DNS входить до складу пакету glibc, а не bind) дозволяє також отримати інформацію з інших джерел ( локальний файл, NIS, NIS+ тощо) залежно від налаштування Name Service Switch. Деякі клієнти дозволяють кешувати інформацію самостійно або за допомогою nscd.

Загальний алгоритм запиту такий: прикладна програма, Якою необхідно, наприклад, отримати адресу хоста на його ім'я, викликає підпрограму gethostbyname(3) або аналогічну їй. При складанні програми до неї приліковуються підпрограми з бібліотеки libc (glibc), які перевіряють наявність необхідної інформації в кеші nscd (якщо, звичайно, запущено сервер nscd). Якщо інформацію з кешу витягти не вдалося, то використовується NSS для визначення сервісу імен, який буде використаний для пошуку адреси на ім'я. Зокрема, у налаштуваннях NSS може бути вказано dns як сервіс імен для пошуку доменних імен. У цьому випадку використовуються функції, вказані в resolver(3), які є “справжнім” клієнтом DNS (вони формують запит до сервера відповідно до протоколу DNS і обробляють відповідь).

Налаштування роботи клієнта DNSвиконується за допомогою файлу /etc/resolv.confабо змінних оточення під час запуску процесу.

Кожен рядок /etc/resolv.conf містить одну інструкцію, коментарі починаються з точки з комою або символом # (обережно! клієнт може не повідомляти про помилки в цьому файлі!):

• nameserver IP-адреса-обслуговуючого-сервера(можна вказати до 3 рядків з адресами серверів; за замовчуванням використовується сервер, розташований на цьому ж хості (його також можна вказати за допомогою його IP адреси або адреси 0.0.0.0 або loopback адреси 127.0.0.1); вказані сервериу порядку їх перерахування, якщо не дочекався відповіді від попереднього сервера зі списку або отримав повідомлення про помилку (недоступний порт на сервері, сервер хост або вся мережа); опитування за списком повторюється кілька разів, залежно від версії клієнта (від 2 до 4); інтервал початкового очікування залежить від версії (від 2 до 5 секунд) та кількості серверів у списку; при кожному наступному проходженні за списком інтервал очікування подвоюється; сумарний час очікування досягає 80 секунд для версії до 8.2 і 24 секунд для нових версій)
• domain ім'я-локального домену(додається до відносних доменних імен перед пошуком; точка наприкінці імені не потрібна; за замовчуванням витягується з доменного імені хоста (див. hostname(1)); ім'я локального доменутакож задає список пошуку за замовчуванням (для bind 4.8.3: ім'я локального домену та список його предків, що мають не менше 2 простих імен; для нових версій bind: тільки ім'я локального домену))
• search список-імен-доменів-через-пробіл(до 6 імен доменів у порядку переваги; перше ім'я в списку встановлює ім'я локального домену; інструкції domain і search – взаємовиключні (виконується остання з них); список пошуку використовується для дозволу відносних доменних імен; для bind 4.8.3 дозвіл відносного імені робиться спочатку за списком пошуку (імена доменів зі списку пошуку приписуються по черзі праворуч від відносного імені перед запитом до сервера DNS), при невдачі ім'я вважається абсолютним і робиться ще один запит; робиться так, ніби воно є абсолютним, при невдачі використовується список пошуку)
• sortlist IP-адреса-мережі/маска …(версія 4.9 і вище; дозволяє клієнту віддавати перевагу вказаним мережампри отриманні відповідей, що містять кілька адрес - їх він поміщає на початок списку, інші в кінець; можна вказувати до 10 мереж)
• options опція …(версія 4.9 і вище; дозволяє змінювати налаштування клієнта
  • debug(На stdout)
  • ndots: число-точок(мінімальна кількість точок в аргументі, при якому пошук на ім'я здійснюється до використання списку пошуку; за замовчуванням – 1)
  • attempts:число-опитувань-списку-серверів(за замовчуванням – 2; максимум – 5)
  • timeout:початковий-інтервал-очікування(за замовчуванням – 5 секунд; максимум – 30 секунд)
  • rotate(при кожному зверненні використовувати інший порядок серверів з метою розподілу навантаження; розподіл здійснюється тільки в рамках одного процесу – при наступному запуску програми перший сервер у списку знову стане першим, що використовується)
  • no-check-names(заборонити лексичну перевірку простих імен, яка включена до версії 4.9.4 та старше)

Конкретна реалізація resolver(3) може мати інші параметри за замовчуванням – дивись /usr/include/resolv.h. Різні програмиможуть бути зібрані з різними версіями DNS клієнта. На щастя, клієнт DNS пропускає незрозумілі рядки з файлу /etc/resolv.conf. Старі версії клієнта DNS (resolv+) можуть керуватися файлом /etc/host.conf, у цьому випадку див. host.conf(5). Деякі програми самостійно встановлюють нестандартні значення параметрів DNS клієнта під час ініціалізації.

Змінне оточення LOCALDOMAIN перекриває дію інструкцій domain та search. Змінне оточення RES_OPTIONS перекриває дію інструкції options. Змінна оточення HOSTALIASES дозволяє задати ім'я файлу (наприклад, /etc/host.aliases), що містить список синонімів доменних імен (по одному простому іменіта його доменному синоніму без завершальної точки на рядку через пробіл).

Якщо під час завантаження комп'ютера потрібна наявність працюючого локального сервера DNS (зазвичай через вказівку доменних імен в ifconfig або route), то бажано забезпечити резервний методдозволу доменних імен за допомогою налаштування NSS та заповнення /etc/hosts, інакше клієнтські комп'ютерибудуть змушені чекати на завантаження одного із серверів DNS. Тим паче важливо забезпечити резервний метод для хостів, у яких працюють сервери DNS. А найкраще не використовувати DNS під час завантаження. Ще є загадковий файл /etc/ppp/resolv.conf.

Налаштування DNS у MS Windows здійснюється за допомогою графічного інтерфейсу. Виробник запевняє, що це дуже просто;). Ось тільки відрізняються реалізації клієнта DNS в різних версіях MS Windows більше, ніж Unix від Linux (зокрема, TCP/IP стек у W2000 і XP взятий із FreeBSD (NetBSD?):

• W95 – окремі стеки для локальної мережі (Control Panel-> Network -> TCP/IP -> DNS) і комутованих з'єднань (My Computer -> Dial-up Networking -> right click на потрібному з'єднанні -> Properties -> Server Types -> TCP/IP); рекомендується залишати при використанні комутованого доступу порожній список DNS серверів в основному стеку і вибирати варіант “Server assigned name server addresses” при налаштуванні комутованих з'єднань
• W98 – візуально налаштування нічим не відрізняється; адреси, що повертаються сервером, сортуються відповідно до таблиці маршрутизації; клієнт працює одночасно і з серверами, вказаними для основного стека, і з серверами, вказаними для даного комутованого з'єднання
• NT – візуально дуже нагадує W95; налаштування для основного стеку (Control Panel -> Network -> Protocols -> TCP/IP -> DNS) і комутованого з'єднання (My Computer -> Dial-up Networking -> вибрати потрібне з'єднанняз випадаючого меню -> More -> Edit Entry -> Modem Properies -> Server -> TCP/IP) використовуються в потрібний час; клієнт кешує отримані результати (не більше процесу); у SP4 клієнт після невдачі з першим сервером починає розсилати запити всім відомим йому серверам паралельно
• W2000 (Start -> Setting -> Network and Dial-up -> right click на Local Area Connection -> Properies -> TCP/IP); поведінка клієнта аналогічна NT SP4

Сервера DNS

Трохи пізніше опублікую статтю про Bind 9

Стаття взята з сайту Bog BOS, автор Сергій Євгенович Богомолов.

Будучи провайдером віртуальної інфраструктури, компанія 1cloud цікавиться мережевими технологіями, про які ми регулярно розповідаємо у своєму блозі. Сьогодні ми підготували матеріал, що стосується теми доменних імен. У ньому ми розглянемо базові аспекти функціонування DNS та питання безпеки DNS-серверів.

Також варто кілька слів сказати про процедуру зворотного зіставлення - отримання імені за наданою IP-адресою. Це відбувається, наприклад, під час перевірки сервера електронної пошти. Існує спеціальний домен in-addr.arpa, записи в якому використовуються для перетворення IP-адрес у символьні імена. Наприклад, для отримання DNS-імені для адреси 11.22.33.44 можна запросити DNS-сервер запис 44.33.22.11.in-addr.arpa, і той поверне відповідне символьне ім'я.

Хто керує та підтримує DNS-сервера?

Коли ви вводите адресу інтернет-ресурсу в рядок браузера, він надсилає запит на сервер DNS, що відповідає за кореневу зону. Таких серверів 13 і вони управляються різними операторамита організаціями. Наприклад, сервер a.root-servers.net має IP-адресу 198.41.0.4 і знаходиться у віданні компанії Verisign, а e.root-servers.net (192.203.230.10) обслуговує НАСА.

Кожен із цих операторів надає цю послугубезкоштовно, а також забезпечує безперебійну роботу, оскільки при відмові будь-якого з цих серверів стануть недоступними цілі зони інтернету. Раніше кореневі DNS-сервери є основою для обробки всіх запитів про доменних іменахв інтернеті, розташовувалися в Північної Америки. Однак із впровадженням технології альтернативної адресації вони «поширилися» по всьому світу, і фактично їхня кількість збільшилася з 13 до 123, що дозволило підвищити надійність фундаменту DNS.

Ще один варіант – використання функції IP Source Guard. Вона ґрунтується на технології uRPF та відстеження DHCP-пакетів для фільтрації підробленого трафіку на окремих портах комутатора. IP Source Guard перевіряє DHCP-трафік у мережі та визначає, які IP-адреси були призначені мережевим пристроям.

Після того, як ця інформація була зібрана та збережена в таблиці об'єднання відстеження DHCP-пакетів, IP Source Guard може використовувати її для фільтрації IP-пакетів, отриманих мережевим пристроєм. Якщо пакет отримано з IP-адресою джерела, яка не відповідає таблиці об'єднання відстеження DHCP-пакетів, пакет відкидається.

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