DNS

1. Історія появи DNS

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

Працівники Стенфордського дослідницького інституту придумали текстовий файл HOSTS.TXT, який містив список рядкових імен та відповідні числові адреси комп'ютерів в ARPANET.

Адреси призначалися вручну. Щоб запитати ім'я хоста та адресу або додати комп'ютер до головного файлу, користувачі зв'язувалися з мережним інформаційним центром Стенфорда за допомогою телефону в робочий час.

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

У 1984 році чотири студенти університету Берклі написали першу версію ієрархічної системи доменних імен. Наразі вона поширена, особливо в Unix-системах, і, як і раніше, є найбільш використовуваним програмним забезпеченням DNS в Інтернеті.

2. Знайомство з DNS

Domain Name System (DNS) – це розподільна система для зберігання та отримання інформації про домени. Вона найчастіше використовується для отримання IP-адресаи на ім'я хоста (комп'ютера або пристрою), отримання інформації про маршрутизацію пошти та/або вузлів, що обслуговують, для протоколів у домені.

Систему організовано як певну ієрархію DNS-серверів, що взаємодіють за певним протоколом. Основою розуміння DNS є уявлення про ієрархічну структуру імені та зони.

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

Система DNS містить ієрархію DNS-серверів, що відповідає ієрархії зон. Кожна зона підтримується як мінімум одним авторитетним сервером DNS, на якому розміщено інформацію про домен.

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

Може бути і навпаки – одному доменному імені може бути зіставлено безліч IP-адрес: це дозволяє створювати балансування навантаження і активно використовується в CDN-мережах.

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

Цікаво! Протокол DNS використовує для роботи TCP- або UDP-порт 53 для відповідей на запити. Традиційно запити та відповіді надсилаються у вигляді однієї UDP-датаграми. TCP використовується, коли розмір даних відповіді перевищує 512 байт.

3. Записи DNS

DNS-сервер зберігає набір параметрів для кожного доменного імені. Це записи про ім'я домену, його IP-адресу, а також різна службова інформація.

Загалом таких записів кілька десятків, тому ми розглянемо лише найпопулярніші з них:

Найцікавіші тут такі:

• A – запис дозволяє встановити IP-адресу, яка відповідає домену.
• CNAME – дозволяє встановити синонім імені, наприклад, www.javarush.com == javarush.com.
• MX – запис містить інформацію про поштовий сервер: що робити, якщо на xxx@javarush.com прийде лист.
• NS — вказує на адресу DNS-сервера, який містить інформацію щодо цього домену. Корисно, коли записи кешуються і зберігаються не на рідних вузлах.

4. Пошук IP адреси

Давай розберемося, як працює DNS-система.

Припустимо, ти набрав у браузері адресу api.javarush.com. Браузер звернеться до локального DNS-сервісу та попросить дати йому IP-адресау для домену api.javarush.com. Далі відбуватиметься ось що…

Спочатку DNS-сервіс дивиться, чи є цей домен у локальному файлі hosts на комп'ютері. Якщо є, то бере IP-адресу з нього. Якщо ні, надсилає запит до відомого йому DNS-сервера: "Яка IP-адреса у api.javarush.com?".

Однак, сервер DNS може нічого не знати не лише про запитане ім'я, але і про весь домен javarush.com. У цьому випадку сервер звертається до кореневого сервера, наприклад, 198.41.0.4. Цей сервер повідомляє: “Я не маю інформації про дану адресу, але я знаю, що 204.74.112.1 є відповідальним за зону com”.

Тоді сервер DNS надсилає свій запит до 204.74.112.1, але той відповідає: "У мене немає інформації про цей сервер, але я знаю, що 207.142.131.234 є відповідальним за домен JavaRush". Нарешті, той самий запит надсилається до третього DNS-сервера і отримує відповідь — IP-адресу, яка і передається клієнту, тобто браузеру.

В цьому випадку в процесі пошуку IP на ім'я спрацювали такі правила:

• Браузер надіслав відомому йому DNS-серверу рекурсивний запит (у відповідь на такий тип запиту сервер зобов'язаний повернути IP-адресу, або порожню відповідь і код помилки NXDOMAIN).
• DNS-сервер, який отримав запит від браузера, послідовно відправляв нерекурсивні запити, на які отримував від інших DNS-серверів відповіді, доки не отримав відповіді від сервера, який відповідальний за зону.
• Інші DNS-сервери, які ми згадували, обробляли запити нерекурсивно (і, швидше за все, не почали обробляти запити рекурсивно, навіть якби така вимога стояла в запиті).

Іноді допускається, щоб запитаний сервер передавав рекурсивний запит "вищому" DNS-серверу і чекав готової відповіді.

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

Допустимий час зберігання відповідей у кеші надходить разом із відповідями (поле TTL ресурсного запису).

5. Файл hosts

Зверни увагу, що спочатку пошук йде в локалному файлі hosts. Це спадкоємець того файлу HOSTS.TXT, який вигадали ще за часів ARPANET. Так, він досі існує і досі використовується.

Він розташований на шляху:

• /etc/hosts у Linux.
• %SystemRoot%\system32\drivers\etc\hosts у Windows.
• /system/etc/hosts в Android.

Зазвичай файл включає визначення розташування вузла localhost:

127.0.0.1   	localhost

Структура його дуже проста: спочатку йде IP-адреса, потім доменне ім'я.

Корисне

За допомогою файлу hosts можна здійснювати фільтрацію реклами шляхом перенаправлення доменних адрес банерів на адресу 127.0.0.0, 127.0.0.1 або 0.0.0.0.

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

Публічний DNS-сервер

Зазвичай ти отримуєш DNS-сервер разом із послугою інтернету, коли ти його підключаєш. Але такий безкоштовний DNS-сервер – не завжди найкращий варіант. Ба більше, можливо, ти б не хотів, щоб кожного разу, коли заходиш на якийсь сайт, до DNS-сервера твого провайдера, надсилався запит з ім'ям домену.

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

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

Такі сервери DNS можуть навіть боротися з шахраями. Наприклад, ти заходиш на підроблений сайт банку, а DNS-сервер віддасть тобі не IP-адресу шахраїв, а своєї служби безпеки.

Список таких серверів